16 years after the start of Python 3 and we're still discussing this. I hope other languages and platforms have paid attention to this transition.
Sometimes one's only purpose in life is to serve as a warning to others...
Sometimes one's only purpose in life is to serve as a warning to others...
Eventually settled for none. I didn't know that at the time, but later it proved to be a career defining moment.
Definitely changed the course of my programming career.
Nothing really wrong with that, but it should have been called "Cobra" or something. And the weird jihad for killing off Python2 should never have happened. If everyone moved to Cobra on their own, great. But there should have been no beatings.
The act of killing off V2 gives downstream developers the right to stop supporting it; regain some focus.
Seems like a strange way to give developers more "rights".
This way there's no expectation, I get to wash my hands of it all. And without an awkward "I'm moving to Viper now chaps". It's a system update paradigm that people understand.
But when you have a few dozen customers on a single product, supporting edge-cases that require core forks becomes incredibly hard. Especially when you need modern Python features.
We tried it. It doubled TTL for simple patches, and meant the Py2 version fell behind in terms of gross features. It was expensive for us, worse for the customer, so we dropped it and moved to a unified core. We had one customer threaten to leave but they didn't. Somebody in their IT department rubbed two brain cells together and agreed with our assessment.
A customer might leave over this sort of behaviour, but again this worked out to be more cost effective, so we would probably do the same when Python 3 is EOL. Wheel keeps turning.
This was the best way to do it. Slowly and painlessly. Any project that matters is now on 3.
For a bad transition, look at Perl 6, a debacle so big it was renamed Raku and became a different programming language.
But it was still full of unnecessary breaking changes.
- The `print()` function is nice, but they could have left in the `print` statement for a transitional (deprecation) period. Or left the `print` statement in, and advise against its use.
- A lot of the incompatibilities are just stdlib modules being moved around unnecessarily. They could have made both import paths work for a transitional (deprecation) period. Or let the old paths continue to work forever, and just document usage of the new paths.
- All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2.
The only true breaking change was unicode literal strings. But again, that could be handled with a slow transitional (deprecation) period. The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have). And users could have been told to `from __future__ import unicode_literals` for a transitional (deprecation) period, to ensure their code is compatible before it becomes the default.
Basically Python 3 could have been a single hard breaking change (unicode literal strings), with a smooth transition. Instead they decided to make Python 2 and 3 diverge from each other, making it harder to do the transition.
They did, it's from __future__ import print_function. python2.7 was, essentially, the transitional deprecation period you mention, and it lasted a decade.
> A lot of the incompatibilities are just stdlib modules being moved around unnecessarily.
six.moves
> - All the new features in Python 3 (async, nice helper functions, etc.) are compatible with Python 2. They could have added them to Python 2.
This assumes a level of similarity in the py2 and py3 codebases that isn't true in practice. There are different bytecodes and 3.0 only optimizations. Backporting some of these is possible, but not a reasonable burden.
>The Python 2 stdlib could have been made compatible with both types of strings (as nearly all third-party libraries have).
I don't know what you're working with, but most third party libs aren't compatible with both types of strings. They're compatible with str or bytes, but not both except in rare and usually wrong cases.
Importing unicode literals only sometimes solves the issues, and often times introduces different problems.
Or do what javascript did: stay compatible with the stupid old way, but build a brand new language on top of it.
Where do you think the idea for `"use strict"` in JavaScript came from?
use v5.8;
use strict;
use warnings;The print statement dates to antiquity (cf. BASIC) and could certainly coexist with the print() function. It was a nice and friendly piece of syntax whose removal was entirely unnecessary.
Now that Python is free of GVR, perhaps we can restore the print statement to its rightful place in the language! ;D
At first glance, you're right. But if you take a closer look, from a purely pragmatic perspective, there are now at least two coexisting ecosystems in two different languages, peacefully sailing along.
Python 2/3 is in this kind of weird twilight zones that the two versions are far away enough that you can't have a smooth transition like in e.g. C++, Java, Rust, Go, etc., but still close enough that there is not a clear cut like in Perl5/Raku. So for a few years, one had to juggle with some of the libs that were 2-and-3 compatible, some that were 2-only, and the others that were 3-only.
C++ et al. let your code evolve Theseus ship-like; Perl makes you build a new ship; and Python tells you that your ship should be OK if you repaint that thing, change a bit of that one, oh, and by the way, you'll have to check very carefully your bunkers, because the boilers will explode if every coal nut is not Unicode-compatible.
Was it really though? Speaking as somebody who considered learning Python several times over the course of a decade I was seriously put off by the protracted uncertainty around 2 vs 3.
There was a long period - years long - where everything that "mattered" seemed to be supported by and available for Python 2 and there was a ton of FUD, along with genuine issues, about incompatibilities with Python 3. When I asked which version I should learn I felt like I couldn't get a straight answer.
I never had a strong need to learn Python: I just thought it might be a fun and useful thing to do, because people seemed to like the language. But I wasn't interested in investing time in something that might wind up unsupported in a few years, and because I didn't have any serious need for it, it wasn't worth digging through the morass of misinformation to get to the truth.
As an outsider it was extremely unclear to me which version of Python would be actively supported for the long term. 20:20 hindsight says 3 was the future but - and maybe this is just bad mar-comms - back then it seemed like there was a reasonable chance it was either going to be a dead end or exist perpetually in this weird no-mans-land of "not quite ready for prime time".
Had I learned it there's a good chance I probably would have used it for something more serious by now. But I didn't, and so I have to disagree: it was done extremely poorly.
And yet Python is still one of the most popular programming languages, with its popularity and use growing.
Theoretically it could have been done better, but it was going to take time no matter what approach you took and it worked out in the end.
[1] http://python-notes.curiousefficiency.org/en/latest/python3/...
Fractured community Lost trust Endless bikeshedding
All for very little objective gain.
I was using it to an extent in 2009. (I'm sure I was using it before that.) At which point it had only been 9 years in development.
---
You can have it fast, good, or cheap. Pick at most 2.
Since Perl 6 was entirely volunteer driven it was always going to be cheap. So the only real choice was between fast and good.
I'm glad the choice was to make it good rather than fast.
We could have gone the Python route where they chose fast. Only they didn't really even manage to do that much better than Perl6.
---
And what did Python get, a language that is only slightly better in a handful of ways. (Every one that I've heard of is reminiscent of one that Perl5 has dealt with over the years without breaking backwards compatibility.)
Perl6 meanwhile is a large step that questions long held beliefs of what a programming language can even be. It calls into question what parsers can be, what regexes can be. It calls into question why language divides exist. Why can't a language be at both ends of the spectrum at the same time.
Even if Raku doesn't take off, it will likely be a source of inspiration for future language designers. (It already has to a small degree.)
Whereas Python3 is just a slightly nicer Python. One that not everyone has transitioned to yet. Some may never. (Some have even transitioned to Go instead, since it has very similar semantics.)
---
There were also some health issues during the Perl6 project which held back the progress to a significant degree. We don't know how many years that added to the total.
https://bugs.chromium.org/p/chromium/issues/detail?id=942720
I'll be dead in my grave before I recognize anything past 5.8.1.
Just like how they still haven't made The Matrix 3.
Sh. Quiet, you. :)