Recently, I posted [RFC] Upgrading LLVM’s minimum required Python version, proposing to bump LLVM’s minimum Python version. Suffice it to say it was “contentious” but with a positive outcome: we’ve gotten permission to decouple our minimum Python version from LLVM’s. Thus I propose we adopt an annual bump schedule and a trailing window of 4 years (4 point releases) 5 years (5 point releases). That would put the start of the window on 3.10. That puts us in lock-step with Python own’s release/deprecation schedule:
Briefly I’ll summarize the reasons from the other RFC for why we should do this, i.e. some features we should be interested in using/developing in our Python bindings:
3.10 – Structural Pattern Matching
3.12 - Type Parameter Syntax (making generic type hints “first class” in the language)
3.12 - A Per-Interpreter GIL
3.13 - JIT Compilation
3.13 - Making the Global Interpreter Lock Optional in CPython
3.14 - Free threaded mode is “officially” supported
There are more mentioned by others in the other RFC.
The draft PR is here and I’ve pulled the same trick as last time (I hand ran all the builder bots on the PR to see which break, i.e., don’t currently have at least Python 3.10 on them). Already there’s one fail (the Windows pre-commit bot) but I expect the total number of fails to be fairly low - the previous experiment revealed about ~25/150 that would need to be upgraded but I suspect only a fraction of those bots are building MLIR at all (let alone the Python bindings).
cc @nikic @boomanaiden154-1 @jpienaar @rolfmorel
10 Likes
I would love to be able to use the structural pattern matching and type annotation features in the bindings. Thanks for all the work on this!
1 Like
Not supporting python versions that are end-of-life seems reasonable to me.
Unless I’m reading it incorrectly, it seems that Python releases are supported for 5 years, where is the 4 years coming from? (5 years also put the start of the window at 3.10 I believe).
Generally fully supportive of this – thanks for championing this, @makslevental!
I will echo that not supporting end-of-life versions makes a lot of sense and puts us on a good cadence. How about adopting that as the/a sufficient reason to do the bumps (which entails moving to 3.10 now and keeping us on an ~annual cycle of bumping)?
1 Like
This seems fine to me, given the tight coupling to Python within the bindings.
Updating the python version in the Windows premerge container has been on my list for a while. I’ll try and bump it up priority wise.
1 Like
“off by one error” - you’re right - I intend to support 3.10, 3.11. 3.12, 3.13, 3.14 until next ~Oct at which point we should be supporting 3.11, 3.12, 3.13, 3.14, 3.15. Saying this out loud I realize it’s ambitious to support the new release on day 1 but actually I think we can do it (if there are “breaking” changes between release, they are usually minor between releases).
Supporting a release on day 1 is very feasible if someone is testing release candidates as they come out.
Ya I mean I do downstream but I don’t have the resources to setup builders upstream to do the same. But anyway I’m comfortable signing up for the day 1 commitment (because I can test downstream and the breaking changes, if any, are usually very minor).
1 Like
Two thumbs up for this RFC! Since we have to interact with the CPython API, developing bindings differs from just using Python for utility scripts. Also, having a clear, codified policy for Python version bumps would spare us the pain of submitting an RFC and re-explaining the rationale to the community every single time we bump.
3 Likes
