In my dreams Python has the stability of Perl, then I'm woken by an alarm that a Python script I wrote 6 months ago uses a now-deprecated feature ...
10 years ago: range 5 years ago: xrange Today: range again, LOL!
I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.
70% is python 2, 30% written/rewritten recently is python 3.
I hope they are paying for security updates since python 2 has hit EOL 3 years ago and libraries had been actively shamed if they didn't drop support for it long before that.
Python 2 code is being transitioned to 3 and there is a plan to do so for all of it, but it's definitely not a highest priority task. Usually done when new features are requested.
This isn't ideal, but it's not a reason to panic. None of the code is externally facing, none of it accepts user input directly beyond a press of a button in third party software that triggers it. All it does is pretty simple stuff. Infrastructure provisioning etc.
Also Python 2->3 transition was a one-time thing that developers had over a decade to perform, it may have been painful for some but saying it's a random thing that happens "every few years" is a bit dishonest.
Some of them (telnetlib) I can vendor in, but I wonder how many people who use them will be caught pantsless?
What has me a little bit confused is that we're in a thread talking about how Python somehow "flubbed" after 2->3, despite an explosion in popularity during that period culminating in it being arguably the most popular programming language around. And the counterexample is supposed to be Perl, a language which I have enjoyed using but which has fallen off a cliff during the same period, and which has had an even more enormous and self-defeating flub (Perl 6 aka "Raku").
As I said, I understand if Python 3.x was painful for some organizations. I think the suggestion that it was a failure and that Perl showed us the right way to go is a pretty silly one though.
It is weirdly comforting to observe how certain things never change over the years, even in tech. One of them is the hyperboles people deploy when attacking programming languages that they do not like: "I don’t know of any tech companies using Python for anything serious anymore". I mean, except for being the 4th most popular language amongst professional according to last year's Stack Overflow survey. Only JavaScript, SQL and HTML/CSS are more popular. Yes, yes, I am sure it is dying... any moment now.
My claim is that the big names don’t really use Python outside of data pipelines. Where I’ve worked (including an org that had had Guido on it for a while) usually had guidance saying “no new Python projects”. You can ask people at Google, Meta, etc when was the last time they wrote production Python code if you don’t believe me.
That’s not mutually exclusive with web devs on Stack Overflow using the language, nor does it take away from its success in academia.
Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?
And same question for grandparents. I'm not a great dev, average at best, but at least I control my systems.
It will then compile for that version.
[EDIT] Check out issue trackers for such projects, some time. "Build broke due to [thing] being too new" is a routine issue to encounter.
Stable features will never be removed or broken. If you don't use unstable features, and aren't relying on something that is unsound, your code will continue to compile. If it doesn't, this is considered a bug and should be reported.
This isn't just a hollow promise either, they run tests against most of the crates on crates.io when making changes to the language to ensure that old code is not accidentally broken.
Claiming that rust isn't a stable language is pure misinformation, but sadly not uncommon.
It's also worth noting that some of the language is specified informally, this is the "reference", there are also RFCs for new features that describe exactly how the feature is intended to work. This isn't a complete formal specification, and could use a lot of work, but I don't think a formal specification with a committee is any better than an informal reference, assuming the reference is exhaustive!
I have, more than once; it worked perfectly fine.
The only time it's broken for me is when the code had unstable nightly-only features, hidden behind a "nightly-only" feature flag, which was rejected by the parser on a newer Rust compiler, even though it would not be compiled due to the feature flag being disabled (even though it wouldn't be compiled, it still had to be parsed; IIRC, it was the change to the inline assembly syntax, and the fix was just to change from "asm" to "llvm_asm").
Outside of 2 -> 3, I can recall only one or two instances of dealing with this in the last 15 years. One was the introduction of "with" and "as" as a keyword. The other one I can't even remember.
None of the code I have written on my personal PC in all these years needed modification due to these changes (all of them were in 3rd party code I needed to patch). I still have Python 2 scripts continually running! I have Python 3.10 installed, and never had to fix a broken script of mine since I switched to Python 3 several years ago.
> 10 years ago: range 5 years ago: xrange Today: range again, LOL!
Eh? When I began using it heavily (before Python 3 existed), both range and xrange were heavily in use - one was a list the other was a generator. Since Python 3 has been stable and fast (circa 2013 or 2014), it's been only range.
Your sample size of one needs expanding.
Citation needed? Just a week ago I used a Python library completely unchanged from 2013.
> Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years.
"Seemingly random" is both wrong and insulting. The BDFL did step down and was replaced with a steering council, so maybe that's what you're seeing. I do agree that `match` was a bad addition to the language, but that's one small example among many supporting the opposite opinion.
> 10 years ago: range 5 years ago: xrange Today: range again, LOL!
Huh? Python 3.x has only ever had range(), so it's been range() for at least 10 years.
perl you really had to properly abuse it to make it actually crash.
Now, some people see that as a feature not a bug (for either perl or python's behaviour)
https://www.tiobe.com/tiobe-index/
This whole Python/Perl competition was always a bit silly. Both languages had and have their place. I would say Python is so much more popular because it found a niche in ML because of how much more easy it is in Python to interface fast C modules. So you get to write simple Python programs leveraging blazingly fast math libraries. That was always a bit more tricky to do in Perl.
But Python as a language is definitely not as flexible as Perl 5. Last time I checked Python didn’t even support multi-line lambdas because its inventor hates those. Python is very much designed in a top-down approach and tries to guide all Python programmers into how there are supposed to solve their problems. Perl 5 was designed with its famous „easy things should be easy, hard problems possible to solve” philosophy. It allows for meta-programming in all the right places which a seasoned Perl developer can reach to when necessary. Perl 5 is a nice middle way between C and Lisp.
That being said modern JavaScript turned into a powerful language that fits well into both the frontend and backend side of a web application nowadays and, hence, kind of replaced Perl as glue language for the web. It will also push Python out of web backends at some point I believe.
Raku / Perl 6 has been the R&D project it set out to be with interesting new features and smoothed out syntax.
You can use either freely as meets your needs. If there's a "debacle" here it's the misunderstanding.
Perl 6 was meant as the bravest experiment with C-like syntax in 30(?) years - attempt to nicely mix few programming paradigms and styles. And that we really have in Raku.
They was talking "Perl is dead" but it never was and isn't. Maybe it looked as clinically death with out of body experience into ideal language heavens but since decade or so it is back. Solid and backward compatible as always.
And there was problem for some with "parallel language versions" marketing so Perl 6 was renamed to Raku. The harder question was "Which one I need to learn ?", but it is newbie programmer question, you need to know many languages because it is standard programmer life experience. And it is XXI century and many technologies are around.
On the other hand Python usage is scientifically researched as being a "write abandonware" language :)
Sorry, but originally it was meant as the replacement (and I was physically present at its announcement at OSCON in 2000). It wasn't until 2008 when the "sister language meme" was generally accepted, that the paths diverged instead of being sequential.
Ok, multi-lang virtual machines wanted to replace Perl5 binary.
But: :)
- multi-lang vm's are proof that v5 syntax wasn't mean to be eradicate at all cost
- there was no plan or push to instantly obsolote, uninstall and deny of Perl 5 usage
- I'm sure there was a conviction that some Perl 5 installations will stay for long time period into the future. Or as long as possible ~~ forever.
So it wasn't like Python 2.7 replacement. And plans even assumed continuation. And some from the start wanted to have both langs :)
To counter that, Inline::Perl5 (https://raku.land/cpan:NINE/Inline::Perl5) was developed. It gives you access to 99.9% of Perl's functionality transparently, such as being able to subclass Perl classes in Raku, and vice-versa.
> Unless it is going through the deprecation process below, the behavior of an API must not change in an incompatible fashion between any two consecutive releases. Python’s yearly release process (PEP 602) means that the deprecation period must last at least two years.
In practice, it's usually longer than two years, except on features that were considered provisional in the first place.