CPython's pre-commit config specifies Python 3.12 for black

Core Workflow
1

For black, the pre-commit config overrides the language version to python3.12 specifically. Since I didn’t have 3.12 on my machine, I tested python3, and it worked fine

I wasn’t sure whether this should just be a gh issue, or a topic of discussion here, so I opted for the more conservative option.

Edited to remove incorrect information about PyO3. I’ll create a new thread for that discussion.

2

Please report this issue to the maintainers of pre-commit; this forum category is for workflow discussion in the Python project itself.

A

1 Like
3

Moved from Core Workflow to Python Help

4

This is about the pre-commit config for CPython, see python/cpython#126971.

(Moving it back.)

5 Likes
5

My mistake! I didn’t realize black was used anywhere in CPython.

3 Likes
6

I just made the same mistake, so I updated the title to clarify what was being discussed.

4 Likes
7

I wonder if we should move pre-commit setup instructions to some more advanced section of the devguide, so it doesn’t act as a roadblock to new contributors.
As far as I know, not that many core devs use pre-commit locally (I certainly don’t). If you’re not actively working on a part of the codebase that requires pre-commit, I think it’s OK to wait for the CI to tell you about the problems, like a human maintainer would.
Apparently, pre-commit instructions are not well tested in various environments. And they’re incomplete – they omit the part where you get the pre-commit command, plus a working copy of Python to get/run it (though needing a specific version looks like a a bug).

2 Likes
8

I’d be in favor of mandatory pre-commit in our workflows if we could make it easy and natural for devs to have correctly installed and functioning on all our tier platforms. (we’re obviously not there… yet)

We have checks that fail in CI that are embarrassing to ever see fail so long after pushing a PR because their fixes could’ve been entirely automated via pre-commit.

4 Likes