[twerkmonsta]

No offense to Guido, and I love Python, but the transition from Python 2 to Python 3 is a reference point for me in terms of how NOT to update a programming language. Noone should ever be attacked, but surely someone deserves some criticism.

[program_whiz]

What was your issue with the transition? Basically both are still usable, and python3 is a huge improvement over python2. I used python2.7 for years before switching and realizing python3 is strictly better, but it was nearly seamless transition (sure legacy projects might have a little pain, but how else can you make fundamental language changes?)

[jbay808]

I like the print function style of print, but unfortunately many of the "My First Hello World in Python" tutorials available online broke when the old print was removed. Those tutorials usually don't make a point of saying they're only valid in Python 2, and of course all new users just learning a language for a first time will download the latest version to try.

For a new programmer, it can be a very discouraging experience having to debug even your first hello world program even though it perfectly matches the code in the tutorial.

[beambot]

What would you have done differently? Frankly, it seemed pretty principled to me -- enough to where I wouldn't be comfortable Monday quarterbacking.

[devit]

Make the 2 vs 3 language decision be module-specific with a single Python executable supporting both languages, allowing you to freely mix Python 2 and 3 files and libraries and thus not splitting the ecosystem.

[eesmith]

I believe that would have been much more expensive to develop, and the Python dev team didn't have the resources for it.

The easiest things can be done by automatic translation, like 2to3.

The remaining parts get increasingly difficult, because Python 2 objects have to know how they are interpreted in Python 3, and vice versa.

A simper step would be to write an AST transformer to instrument Python 2 code and identify the non-Python 3-compatible uses of, for example, keys() and values(). That's almost as hard as writing a Python 3 implementation in Python 2, and I couldn't convince myself that it made financial sense given that it would still miss a lot of corner cases.

[joshuamorton]

They did that where possible (from __future__ imports, forwards compatibility changes to a bunch of internal apis (the C extension api, as well as stuff like the code object)), but there's not a cross-compatible way to handle the unicode/bytes change. Python2 has, essentially, a single text-bytes str type. Python3 has different ones. You can't cross that boundary from 2 to 3, because the runtime has no way to know which of text or bytes a given str is.

What you can do is use libraries like six to make code run just fine in both versions, and six-ify on a per file basis. This works pretty well.

[zb]

It is universally acknowledged that the strategy prior to 2.7/3.3 was wrong, and that this delayed the transition by several years.

[basic6]

the := PEP stunk badly of cargo cult programming, you see knee-jerk proposals like that every time a blog makes the rounds and Guido deserved the pushback

[wyldfire]

I had to look this one up. PEP 572 [1] introduces "the walrus operator". Your claim that it "stunk badly" made me think that perhaps it was proposed and rejected, however it's listed as 'accepted' and among the new features from CPython 3.8. I suppose if you're the BDFL you can get your PEPs approved ;)

AFAICT it allows for optional binding. I suppose it might seem like 'cargo cult' because Rust and Swift have 'if let'?

[1] https://www.python.org/dev/peps/pep-0572/

[basic6]

It was accepted but that PEP caused the whole kerfuffle correct? It became fashionable to have a strong opinion on assignment vs equality.