I think partly to blame is the people who refused to move to 3.x. I remember in 2016-17 I worked on a new project and people say and argued that we simply had to use 2.x and that it would never go away. There wasn't even 2.x dependencies for the project. And I feel like that kind of mentality really slowed down migration and ultimately helped to create a culture that python would always be changing.

It's an interesting point, both the argument it makes and the background.

I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerous and totally unnecessary minor syntax changes (print -> function, map and filter becoming lazy, str/unicode etc) with no major benefits in the upgrade for my use case (data science), other than compatibility. Some of the new syntax was neither bad or good (what's so wrong with print being a statement? Add a printfn function if you really want one), some were IMHO outright bad (map and filter becoming lazy, reduce being kicked out to a module), str->unicode was maybe the only good one, but even that is controversial. The deliberate neutering of `bytes` was unnecessary too. Python 3 brought various implementation improvements and nice new syntax, which could have been implemented in a Python 2 syntax too (dict and set comprehensions for example)

So I saw no reason why Python 3 couldn't in fact be syntactically compatible with 2, and saw the whole thing as a bit of an upgrade circus: wanna keep using the language? Make these arbitrary changes because someone thought print ought to be a function.

You could argue it was the same disregard for stability as the now many versions of Python 3.

Why print as a function?

From the PEP[0]:

    print is the only application-level functionality that has a statement dedicated to it. Within Python’s world, syntax is generally used as a last resort, when something can’t be done without help from the compiler. Print doesn’t qualify for such an exception.
    At some point in application development one quite often feels the need to replace print output by something more sophisticated, like logging calls or calls into some other I/O library. With a print() function, this is a straightforward string replacement, today it is a mess adding all those parentheses and possibly converting >>stream style syntax.
    Having special syntax for print puts up a much larger barrier for evolution, e.g. a hypothetical new printf() function is not too far fetched when it will coexist with a print() function.
    There’s no easy way to convert print statements into another call if one needs a different separator, not spaces, or none at all. Also, there’s no easy way at all to conveniently print objects with some other separator than a space.
    If print() is a function, it would be much easier to replace it within one module (just def print(*args):...) or even throughout a program (e.g. by putting a different function in __builtin__.print). As it is, one can do this by writing a class with a write() method and assigning that to sys.stdout – that’s not bad, but definitely a much larger conceptual leap, and it works at a different level than print.

[0] https://peps.python.org/pep-3105

Yes, if Python was made from scratch, then perhaps function is better (I don't really mind).

But breaking one of the most commonly used statements for what is essentially aesthetics? No thanks. Introduce a function that does the same if you like.

That's precisely my point, this syntax change (and many others) was entirely unnecessary, put people off upgrading, then got them told off for being dinosauric luddites.

Frankly, it's not even that consistent. Is `del dict[key]` necessary when you can call `dict.pop`?

Either way, these would be fine discussions to have, but not when you consider the people upgrading thei codebases.

> Is `del dict[key]` necessary when you can call `dict.pop`?

Reason for Python 4 detected!

Can't override/hack `print` as a statement, which is something I've found myself doing often enough to be happy that it's a function.

I mean I do think Python 3 introduced some pretty bone-headed things. Their strings are horrible if you need to interact with the system. Most system APIs on UNIX-like systems don't promise that anything is UTF-8-encoded, so you can't e.g use strings to store paths. You need to use byte strings, and they have WAY worse ergonomics in many ways than strings.

I would never use Python 2 now, but I do understand why some people would choose 2 back when 3 was new (and even slower than 2!).

> so you can't e.g use strings to store paths. You need to use byte strings, and they have WAY worse ergonomics in many ways than strings

Would you not use Pathlib?

But isn't exactly that the reason for the string/byte split?

Rust has a similar thing with OsStr. In my opinion a clear type based separation between different kinds of strings (Text, data, os path, ...) is just required to write robust softwsre

I'm still not clear on what the real benifit of python3 over 2 was.

I use python3 now by default, as it has fstrings, and probably some iteration things that I now rely on, and is faster for a lot of things.

But for the longest time the only difference that I bumped into was that print isnt a keyword anymore, but assert still is.

The main breaking change was Unicode for strings, which is what caused all the pain as lots of code was written to assume ASCII strings.

But it's good that it's Unicode.

Ahhh yes, that brings back memories. This also meant that stuff coming from things like UARTs and sockets were binary, rather than strings in python3.

For anyone who doesn't remember: A python3 design decision they went partially back on meant it was easier to go from 2.7 to 3.3 than it was to go from 2.7 to 3.0

(I think it was 3.3 when they compromised, maybe 3.4?)

3.3 - they reallowed unicode literals.