Another critical mistake python 3 made was unicode support. For people who work deeply in i18n support, UTF-8 encoding is the only practical solution. Python 3 string should use UTF-8 much like Go. Just for reference, Google stores almost all data as protobuf, which only support UTF-8. That proves the story.
I don't understand where you see the mistake in Python 3 with unicode. What encoding Python internally uses to store strings doesn't really matter. What's important is that it is always known what encoding is used. This was unclear in Python 2 and Python 3 fixed this.
I can't speak to the wisdom of making map and zip builtins, but that's what they are in py3, and the six module will make using them that way automatically backward and forward compatible:
from six import map, zipIt is the same as the `u` prefix. Those who actually cared to get Unicode right got punished when Python 3.0 came out because now none of their code compiled, whereas those who just assume everything is ASCII went on without problems.
If nothing else, I feel that backward compatibility should be given toward's a language's canonical "hello world" example.
To me this is the main pain point and I'm surprised that people are not talking about this.
2to3 and 3to2 are too kludgy and writing native py2-and-py3 compatible code is quite painful and requires a number of workarounds (e.g. unicode/str/bytes type, different methods on dictionaries...)
Why is changing 'print stuff' to 'print (stuff)' such a big deal?
I think 2To3 solves a lot of print cases https://docs.python.org/2/library/2to3.html
You certainly don't have to do it if you don't want Python 3 and 2to3 makes it a lot easier
Actually no, it hasn't. PEP8 is just a formatting standard, your code will work with your own standard too.
Yes, a lot of people need to get that memo
I don't like it as well, but it keeps a group of developers in check. And it can be configured, so there's that as well
Too bad autopep8 produces bad results out of the box
But the print statement was one prominent, attractive way that Python was essentially pseudocode-- its removal seems an improvement from a pedantic sense, but one that seems to run contrary to convenience and (perhaps) the expectations of a beginner.
I don't think it could (easily) be resolved by treating it like a function when followed by parens and a statement otherwise. For illustration, consider what happens when you use parens after print in Python 2: the parens are treated like they would be in a mathematical expression — only there for the sake of order of operations. The parens effectively disappear when parsing.
As an end user, I say drop 3.x support in your libraries. The gig is up. If 3 ever takes over, do a 1 time wholesale port and drop 2. Tell people who want 3.x support before then to port and maintain it themselves. Enough complaining.
People dropping 3.x support until 3.x becomes the most used version basically guarantees that it won't take over.
Is this a code equivalent to the bystander effect?
Few to no one in userspace asked for this problem. For me, it's not a problem. I suspect a lot of people will eventually see it my way. Instead of learning/porting from 2 to 3, they'll stick with 2 and pickup something else like Go. I believe adding Go to my toolbelt was a much better use of my time. While there's other, maybe better, choices than Go, my argument is that it's so easy to learn that it's just about as difficult as the transition/porting of existing projects that Python3 would've been.
I personally gain little to nothing by spending any time on Python3. No amount of features, moving distros to 3 by default, or anything else can convince me. All job prospects 2, and all the libraries support 2. No one cares if my resume has Python3 on it, but adding Golang alongside Python2 opened up a lot of opportunities. If a Python(2) user wanted to spend time on Rust, that would also be a great use of time.
For each person I see demanding Python3 support, I want to see that person spending hours, weeks, months, porting everything they can find to 3 and then maintaining it. Because the rest of us don't care.
For me, Python3 has 1 main feature. It enables you to beg library maintainers to port to 3.
Compare that to unicode changes, where you need to manually inspect and potentially deeply analyze every single string literal.
Why waste resources making the trivial easier just to please people that will not migrate anyway?
I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly?
These aren't fun problems. Improving python 3, making it more attractive, that's fun. But that's problem 2. Making migration less painful for me should be problem 1. Who's working actively on that?
What particularly grinds my gears is the apparent disregard for migration in the design. Take the changes to the print statement. Often this is the only thing that prevents my existing code from working in python 3. And it's in my muscle memory so I always get snagged when debugging on python 3. For what? Take a read through the rationale: https://www.python.org/dev/peps/pep-3105/#rationale. Most of the benefits you could have had if you'd named the new print function something else. I can understand that you regret adding it in the first place. What's even worse though? Adding it and then removing it in an incompatible way.
If you want to make python 3 more attractive maybe make migration easier before going on to the fun improvements? There are low-hanging fruits for migration too. How about adding back the print statement?