Support CPython+t in ICs to select free-threaded CPython.

[jsirois]

No description provided.

[sureshjoshi]

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?

[jsirois]

Yes.

[sureshjoshi]

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).

[jsirois]

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.

[jsirois]

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).

[sureshjoshi]

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.

[jsirois]

It was intentional in the strategy of implement what is asked for and no more as long as it doesn't close off 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.

[jsirois]

Alright @sureshjoshi, this is ready for another look.

[sureshjoshi]

👍🏽

You then asked, and you 1/2 count (I assume you don't actually need this but are anticipating an actual user need)

I don't "need" it per se, but I ran into it by accident that day, while doing an unrelated test of uv as a python provider pants plugin. That's what ended up triggering my question, actually.

Just ran it now on that machine, and using any permutation of the gil-less, gil-full, and gil-ambiguous constraints work as I would expect now.