No matter what anyone says about how it finally succeeded: taking a decade is just plain disastrous. Saying "a language has to evolve" is vapid and meaningless. "Change" per se is not good OR bad in itself.
To start with, 3 fixed a lot of things that were not really broken. As Jasper_ says below, "Python 2.8 would have been a much smarter idea."
All future generations should remember the Python 2 to 3 transition as the one time in history that a programming language successfully made a breaking change so far into maturity and survived, and only just by one single fingertip holding on to avoid falling into the abyss below.
It will be interesting to see how Scala 2->3 goes. The timing is good. After an initial boom, interest in Scala settled back into a smaller niche than expected, and since that happened entirely under Scala 2, it won't be blamed on the transition to 3. The smaller community will be easier to help through the process, and the tooling and compatibility are better thanks to Scala being a statically typed language. Having the example of Python to follow (or not, where appropriate) doesn't hurt, either.
I really can't say if you're serious or joking. Python's transition can only be called 'successful' if the plan was to inflict as much pain as possible on maintainers of Python projects (and nowadays, Typescript via Deno doesn't really look all that bad for new projects where I would have used Python before).
If the 2-to-3 transition hadn't left so many scars, the idea to switch to a different language for cross-platform command line tools wouldn't even enter my mind. Python 2.x was just perfect for this use case, and Python3 didn't add anything of value for such scripts.
What example is C# exactly? Never struck me as anything reaching wide adoption outside of the enterprise MS market, and you can certainly change anything if your customers already sunk the licensing cost. I certainly never and will never touch it, with or without incompatible language changes.
And hundreds of commercially used programming languages during that period. It might be a short history, but it's littered with the corpses of languages that failed to change when they should have =)
Yes, because .NET was so old and mature that it's not like you suddenly received updates from all around that your computer couldn't run. By the time .NET 5 was popular enough everyone could have the runtime. And if not, your software were advanced enough and your devs competent enough in the old ways that you could enact change for years.
I suffer from that at work (I have 200 users on .NET and dozens of servers needing some python): we dont have the runtime for .NET 5 installed on windows yet, and we dont have python 3 on many older servers. There is one part where we suffer immensely, and another where we barely care: I let you guess which one.
If python3 just brought print(), it would not have been worth it. But bytes and string, totally worth it. I never once had problem with encoding in python3.
The Python 2-3 transition was terrible and may have changed the course of my career.
I was just getting into programming and thought Python would be a good place to start, but ended up being put off by the schism between the two versions. It seemed like everything I looked at was filled with caveats about not being compatible with one version or the other. I thought 3 sounded like the better choice since it was newer, but so many learning resources were stuck on 2 with no plans to upgrade, but I didn't want to be stuck on an old version, and I didn't have enough experience to make an informed decision.... So I eventually ended up dropping Python entirely.
Maybe now is a good time for me to revisit Python if that isn't an issue anymore.
Even though he considers things like `require('./something')` defaulting to either `./something.js` or `./something/index.js` a mistake, he also admits these are not possible to change at this point.
I think Python made a mistake trying to correct design problems in 2. The cost of change simply wasn't worth the price of migration. Is `print("text")` really that much of an improvement over `print "text"`?
Python 2 string handling was really quite a mess compared to Python 3, and fixing it would have required manual intervention in any case (since it wasn't possible to distinguish usage of strings in Python 2 from raw byte sequences in a lot of cases). I think the print statement to function part of it was a way way more minor pain point compared to the str/unicode change, and is a fully automatable transformation anyway.
It’s interesting how the article reads linearly but the change for my code as was not.
My new projects went to 3.5 and my existing codebse got maintained at 2.7 until a version update opportunity arose.
It took a few years to get everything over.
Next time something like this happens, something like Chat GPT will make it much more seamless. "Chat GPT, please rewrite this program to be Python 4 compatible"
You say that, but the 2to3 tool did a brilliant job of doing just that, and as it understood the AST it actually didn't try to bullshit like ChatGPT and Co-Pilot do at time.
I use Co-Pilot, it's super helpful but, god it's good at bullshitting. Sometimes you think "wow" but then stop and look what it's done and it's all very wrong, but looks very right. Although that's only like 10% of the time.
Im looking forward till they combine Co-Pilot with the static analysis tools you have with statically typed languages, that is going to be so much better.
Is it a stronger argument if there is a proof establishing an upper bounds of "pathological derangement" with regard to large language model AI?
Wonder if that would lead to regulations around language model "strength tiers," and whether certain industries will even allow Copilot or ChatGPT-like code.
Here's one of the things that honestly surprised me about the Python 2 -> 3 debacle. I witnessed people in 2020 starting new Python projects and deliberately choosing Python 2. For no real reason. They were fully aware that Python 3 existed, but they just sort of arbitrarily chose to use Python 2. This was about 12 years after Python 3 was originally released, it was after Python 2 was sunset, and none of the dependencies of these projects required Python 2.
It honestly makes me feel a little nihilistic about versioning and upgrades. I know there were many legitimate technical challenges for many people in moving from Python 2 to 3. But I now feel that versioning is always going to be bumpy, regardless of the technical issues, because a substantial number of users will make strange decisions.
It was not for no reason. It's that people knew Python 2, whereas for many what they knew about Python 3 was:
- I heard it is a lot of work to switch over (must be pretty different!).
- Learning more about it is on my todo list, but I haven't had a chance to get around to it yet.
That's not to excuse their decisionmaking from a do-the-right-thing standpoint, because they weren't doing right by their clients, but I feel it's totally understandable. I remember speaking to conscientious engineers a few years before that who only knew a smattering of Python from the 2.7 era and were apprenhensive about starting a new project in 3.x. Sometimes you just have to hold people's hands a little. Maybe not a "good" reason, but so it goes.
Whenever I hear about some useful proposal for C++ being shot down because “this would be a breaking change” I gnash my teeth in frustration, but then remember the python 3 debacle and calm down.
In fact a lot of my frustration with C++ evolution is due to the committee’s experience of having made a couple of bad decisions that had to be undone (like auto_ptr), or which are unrepairsble (overconstrained unordered_map). Which is a great example of why you shouldn’t have someone like me on the committee!
My hope for python 4: find a way to accept both styles of something (eg `print foo` and ‘
`print(foo)`), with deprecation warnings. Deprecation warnings would be something new in Python as it’s not “compiled”, but if a way was figured out then you could eventually yank the old behavior after a date far into the future.
How much money and time was spent, collectively, updating projects, OS packages, and broken dependencies due to this transition? My guess is about $2B.
It took bold and determined leadership to make the breaking changes necessary to do things the right way. There were plenty of entrenched interests that would have preferred to keep doing things the wrong way because it was easier in the short term. If GvR and the rest of the core developers had been cowed by the reactionaries, Python would have stagnated. Instead, they persevered, and the language is much, much better today because of it. Woe to those of us who still have to use Python 2.
More "reluctantly" than "badly". Sure, millions of projects and bindings and people and tools all had to be convinced to transition independently, but they did. Kicking and screaming, and dragging their feet for as long as possible, but: they did.
"Badly" would be if Python 3 had died after a prolonged death bed (I see you, Perl 6), but instead Python actually got there, in spite of all the haters.
(initially justified haters, of course, but that just makes it all the more impressive that 3 wasn't abandoned before it got all the polish it needed before it could prove it was worth the effort)
There were a lot of people that left Python for other languages and never came back in the whole 2 to 3 debacle.
It doesn't help that the early versions of Python 3 were really opinionated and terrible. Python 3 only took off after they walked back a lot of the strong opinions that made them do a language break in the first place.
Knowing what is known now about the transition, Python 2.8 would have been a much smarter idea.
That said, knowing what is known now, the transition also would've been smoother. Deprioritize "2to3", and require single-codebase-compatibility features from the start. Maybe even decouple the C API change release from the language change release.
> It doesn't help that the early versions of Python 3 were really opinionated and terrible
Isn't opinionated kind of Python's thing? I can understand "terrible" being bad, but like, "terrible and unopinionated" sounds bad as well. As someone who never really bought into "there should be only one way to do it", it's kind of hard not to be amused at the thought of the Python community suddenly realizing that maybe being too opinionated can sometimes be a bad thing.
I never claimed that they were good at following this philosophy, just that they espoused it. Maybe they've let up because being opinionated stopped working.
Absolutely, but it's not a static pool. A lot of new folks happily use 3.10 today that would have looked at 2.7 and gone "what century is this? No thanks", so even if on an individual level Python 3 might feel like it failed you, as a programming language it succeeded in changing with the times and staying not just relevant, but actually popular.
I'd say that the biggest change for me was migrating string to unicode. But since I usually work outside ASCII, migrating to Unicode has made python much saner to me...
No matter what anyone says about how it finally succeeded: taking a decade is just plain disastrous. Saying "a language has to evolve" is vapid and meaningless. "Change" per se is not good OR bad in itself.
To start with, 3 fixed a lot of things that were not really broken. As Jasper_ says below, "Python 2.8 would have been a much smarter idea."