If the first question you’re asking yourself looking at a code base is “what version is this/do I know this version” then that language is not facilitating you.
The successful languages are ones where “the community” prioritises backward compatibility. Java, C, Python have backward compatibility spanning decades. There’s a few discontinuities (lambdas in Java 8, Python 3, C++) but in most cases there’s a clear mapping back to the original. Python 3 is an exception to this but the migration window was something like 15 years…
Busy engineers, scientists and academics have little interest in keeping up to date with language features. A computer and a programming language are a tool for a job and the source code is just an intermediate artifact. These are your “community”, and the stakeholders in your success.
There are hardly any non-toxic programming communities out there. And if you value backward compatibility over everything else you can look at C and C++.
I dunno it was 20 years ago I jumped ship when they tried shoehorning object oriented semantics into it. Eugh.
Doesn't mean I have to deny them the right to exist because they don't have a "community*".
* more like a religion for some programming languages.
Perl6 had been renamed to new language, Raku.
This can in turn fuel development of the platform therefore helping keep it relevant.
In recent times we call this “the network effect” and it applies to more than just social media.
from __future__ import annotations
requires-python = ">=3.9" $ python3.13 -c 'from __future__ import awesome_feature'
File "<string>", line 1
SyntaxError: future feature awesome_feature is not defined
Anyway, I'd guess what they intend is
try:
from __future__ import fever_dream
except SyntaxError:
fever_dream = None
use v5.40;
....
(I'd argued for that feature for years with my `Modern::Perl` feature bundle; glad to see that can be deprecated now.)
Further, the changes were made for very good reasons, such as allowing beginners to accept user input on day 1 without opening ACE exploits in their programs, and having plain double-quoted string literals actually produce a string rather than an immutable byte buffer that vaguely assumes a generic code-page encoding, except for the contexts where it will complain if it's not plain ASCII (admittedly, this is still an improvement over trying to handle text in C with only the standard library), and making sure that decoding operations don't produce encoding errors and vice-versa, and making `isinstance(1<<64, int)` give the expected `True` result, and making `except` syntax make sense, and making sure there aren't two fundamentally different kinds of user-defined class.
And by making these changes, we actually got Python 3 in about 2.5 years (4.5 if you allow for the first couple of releases having some issues figuring out the string literal transition and other such details — I agree they were premature) and were able to offer another 11 (9) for everyone to migrate. Whereas with Raku the entire 13.5 (more like 15.5) year period was spent on design and implementation, and now there hasn't been a new stable release for almost 5 years.
A major new version of Perl ships regularly. A few weeks ago the latest major new version shipped. From the 2025 changes document:
> Perl 5.42.0 represents approximately 13 months of development since Perl 5.40.0 and contains approximately 280,000 lines of changes across 1,600 files from 65 authors.
Skipping back 5 major new versions (to 2020):
> Perl 5.32.0 represents approximately 13 months of development since Perl 5.30.0 and contains approximately 220,000 lines of changes across 1,800 files from 89 authors.
2015:
> Perl 5.22.0 represents approximately 12 months of development since Perl 5.20.0 and contains approximately 590,000 lines of changes across 2,400 files from 94 authors.
2010:
> Perl 5.16.0 represents approximately 12 months of development since Perl 5.14.0 and contains approximately 590,000 lines of changes across 2,500 files from 139 authors.
There's been well over 10 million lines of code changed in just the core Perl codebase over the last 25 years reflecting huge changes in Perl.
----
Perl 6 ... isn't backward compatible
Raku runs around 80% of CPAN (Perl modules), including ones that use XS (poking into the guts of the Perl 5 binary) without requiring any change whatsoever.
(The remaining 20% are so Perl 5 specific as to be meaningless in Raku. For example, source filters which convert Perl 5 code into different Perl 5 code.)
----
But you are right about one thing; no one you know cares about backwards compatibility, otherwise you'd know the difference between what you think you know, and what is actually true.
What the hell is this? Even if nobody I know cares about backwards compatibility, how does this relate to whether my knowledge is true or not?
Apologies for trivializing perl5's progress in the past 25 years, but come on, chill out dude.
Unfortunately, python's developers seem to have demonstrated tremendous contempt for the users of the language, and for existing code bases.
Other languages (though not all.... <cough, swift>) have actual language specifications and standards (that even keep working as runtime systems evolve), and are not so keen on throwing users and their code off a cliff.
Platforms should absorb pain so that their users don't have to, and avoid introducing breaking changes that multiply pain across an entire user base.
Apple (also known for arrogance combined with contempt for their developers) also gets this wrong, and routinely breaks iOS and swift apps every year.
Open source implementations are fine, though the "if you don't like it fork/make your own" argument is, typically a way of sidestepping criticism rather than a practical solution.
But one of Python's greatest weaknesses is that there is no formal language specification. All you have are implementations and their documentation.
Can you give a concrete example of a problem you encountered while porting 2->3 code caused by a poorly chosen default in 3?
> compatibility features and libraries
You mean like `lib2to3`? Or all the backports 2.7 got, e.g. what's listed at https://wiki.python.org/moin/StandardLibraryBackports ? Or the `__future__` system? Or third-party support like `six` (still immensely popular, though presumably only in CI)?
> the print statement (which could have coexisted with a print() function)
No, it absolutely could not have. Not with the same name, and making the name refer to the function was the point. The print statement syntax was inelegant, quirky and confusing. For example, parentheses can affect the meaning in unusual ways:
$ py2.7 -c 'print (1,); print 2'
(1,)
2
$ py2.7 -c 'print 1,; print 2'
1 2
> python's developers seem to have demonstrated tremendous contempt for the users
I don't understand how you have come to infer such an attitude. Any suspicion that they are introducing breaking changes on a whim will be immediately quashed by reading the discussion behind any of those breaking changes. (Not to mention what happens with the rejected proposals.)
> and avoid introducing breaking changes that multiply pain across an entire user base.
What breaking change was introduced in Python 3.x during your history of using it that caused a nontrivial problem for you? How many years do you believe you were given to account for it?
C++ is still faster than PyPy3, but not 10x faster. That is good enough for me to not deal with the messy C++ syntax.
It could have fairly trivially for the vast majority of use cases (no space between print and parenthesis if you want to call the function) but apparently that would have made some python maintainers unhappy. So it was ripped out and a breaking change was introduced with no recourse (not even, say, from __past__ import print_statement or something).
This is part of what I mean by demonstrating tremendous contempt for the user base and for existing code.
This would be unlike anything else in any ALGOL-extended-family language, never mind Python.