Comment by Hamuko
15 days ago
Being three major versions behind CPython is definitely not a great sign for the long-term viability of it.
15 days ago
Being three major versions behind CPython is definitely not a great sign for the long-term viability of it.
It's always been about that many versions behind.
There is more churn in those versions than you'd think.
I'd genuinely be curious what fraction of those changes actually requires porting to other Python implementations. The free-threading changes are inherently interpreter specific, so we can ignore those. A significant change in Python 3.12 is dropping "dead batteries", so that can be ignored as well. From what I can see, the main language changes are typing-based (so could have parser implications), and the subinterpreter support being exposed at the Python level (I don't know whether that makes sense for PyPy either). I think this hints that while certain area of Python are undergoing larger changes (e.g. typing, free-threading), there is no obvious missing piece that might drive someone to contribute to PyPy.
Also, looking at the alternate (full) interpreters that have been around a while, PyPy is much more active than either Jython or IronPython. Rust-python seems more active than PyPy, but it's not clear how complete it is (and has going through similar periods of low activity).
Would I personally use PyPy? I'm not planning to, but given how uv is positioning itself, this gives me vibes of youtube stating it will drop IE 6 at some unspecified time in order to kill IE 6 (see https://benjamintseng.com/2024/02/the-ie6-youtube-conspiracy...).
The problem is the million small paper cuts. The stdlib changes are not all in pure python, many have implications for compiled modules like _ssl. The interpreter changes, especially compatibility with small interpreter changes that are reflected in the dis module, also require work to figure out
I'm not sure "major versions" is the most correct term here, but I think your point is spot on
For Python, 0.1 increases are major versions and 1.0 increases are cataclysmic shifts.
I don't know about that. For me, f-strings were the last great quality-of-life improvement that I wouldn't want to live without, and those landed in Python 3.6. Everything after that has not really made much of a difference to me.
8 replies →
They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.
Or at runtime, you can import things from the standard library which require a minimum 3.x. - .x releases frequently if not always add things, or even change an existing API.
> They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.
Are you saying that you'd get an error using the new feature on an old version, or that code that used to parse on old versions would not longer work on the newer version? The former is pretty much a textbook example of a minor version update in "traditional" semver; a single new API function is enough to potentially make new code not work on old versions, since any calls to that function will not work on versions predating it. The latter is what would constitute a "breaking change" in semver; old code that used to work can't be made to no longer work without a major version bump.
I say "traditional" semver because in practice it seems like there are fairly few cases in which people actually seem to fully agree on what semver means. I've always found the "official" definition[1] to be extremely clear, but from what I can tell most people don't really adhere to it and have their own personal ideas about what it means. I've proposed things in projects that are fully within both the letter and spirit of semver quite a few times over the years only for people to object on the basis that it "isn't semver" because they hadn't fully read through the description before. Typically I'll mention that what I'm suggesting is something that semver allows and bring up the page and show them the clause that specifically allows what I'm saying but clarify that I recognize we still might not want to do it for other reasons, and the other person will end up preferring to stick with their initial instinct independent of what semver actually says. This is totally fine, as semver is just one of many versioning scheme and not some universal optimum, but my point is that it's probably more confusing for people to use the same term to describe fairly inconsistent things.
[1]: https://semver.org/
1 reply →