This is a new one on me …. Python is unstable?
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)