Support CPython_t in ICs to select free-threaded CPython.
#3067
Conversation
| 'e.g. "CPython>=2.7,<3" (A CPython interpreter with version >=2.7 AND version <3), ' | ||
| '">=2.7,<3" (Any Python interpreter with version >=2.7 AND version <3) or "PyPy" (A ' | ||
| "PyPy interpreter of any version). This argument may be repeated multiple times to OR " | ||
| "PyPy interpreter of any version). The recognized requirement names are `CPython` for " |
There was a problem hiding this comment.
Just confirming my understanding re: tests and re: release notes against this help message.
The CPython name captures classic + free-threaded, while CPython_t is strictly free-threaded?
There was a problem hiding this comment.
Do you intend to add a mechanism to deterministically enforce non-free-threaded builds? Similar to uv’s +gil idea: https://docs.astral.sh/uv/concepts/python-versions/#free-threaded-python
Or do you think that that be better handled at a higher level (e.g. Pants providing an option to limit to gil-builds).
There was a problem hiding this comment.
I did not intend to, no. But I'll do so, instead just allowing selection on abiflags. So, CPython maintains the current meaning of any CPython, and CPython+t means CPythons with the t abi flag (free-threaded), and CPython+t-d means CPythons that are free-threaded but are not debug builds, etc. Basically same level of complexity in the code support but cut these questions off at the pass.
Or do you think that that be better handled at a higher level (e.g. Pants providing an option to limit to gil-builds).
You have no way to do this at a higher layer unless you stop using Pex for interpreter discovery or you do something super complex like probe pythons on the PEX_PYTHON_PATH / --python-path you set up and arrange the ordering of said PEX_PYTHON_PATH / --python-path to ensure earliest on the search path satisfies the users needs. At that point though, you're doing interpreter discovery yourself basically; so this would seem tortured.
Basically, I'm super confused why you'd suggest this.
There was a problem hiding this comment.
Ok, I'm shelving the full abiflags handling. It's both more complicated than I imagined and I don't truly grok the landscape over time; so I'll punt but stick with the syntax. There will now be exactly 4 implementations:
- CPython: Any CPython implementation (as is today).
- CPython+t: Only CPythons built with free-threading support.
- CPython-t: Only traditional GIL enabled CPythons (i.e.: CPythons built without free-threading support or 3.12 or older CPythons where there was no such support at all).
- PyPy: Any PyPy implementation (as is today).
There was a problem hiding this comment.
At that point though, you're doing interpreter discovery yourself basically; so this would seem tortured.
I agree.
Basically, I'm super confused why you'd suggest this.
The ability to select any python, and strictly free-threaded, but no ability to strictly select no-gil seemed like an obvious gap - I assumed it was intentional, that’s all.
There was a problem hiding this comment.
It was intentional in the strategy of implement what is asked for and no more as long as it doesn't close of avenues - let someone complain to fill in the gap later.
No one asked for GIL-only, so I was defaulting to not supporting that yet. You then asked, and you 1/2 count (I assume you don't actually need this but are anticipating an actual user need); so adding it now.
This is a more comprehensive test as well.
2 participants
No description provided.