The point you're missing is that is that is was another change, for changes sake.
You're right, a print() statement is better than just print, but it was an unnecessary change, that was made 'for the best' without sufficient justification.
Python3 allowed the devs to fix some of the mistakes or sins of the past
Unfortunately, historically, it seems that it would have been a far, far better choice to roll those fixes out incrementally, even if it meant multiple breaking changes.
It was too many changes, all at once.
I think the lesson here is that time and time again, 'big bang' breaking changes have been failures.
2to3 should have made this a trivial change; but that only holds if 2to3 actually worked for every other simultaneous breaking change (it didn't).
A far, far more mature and better approach would have been the 3.x line being a continual stream of breaking changes with a flawless 2to3 that converted 100% of every python2 program to working python3, and a series of 3.xto3.y migrations that flawlessly upgraded python3 code until all breaking changes had been worked out.
Imagine if you had a series of transformations you could apply to any python2 project and you could incrementally migrate it automatically to 3.5. That is what we should have had. Screw print statements; invest in meaningful stuff when you make breaking changes.
I do scientific programming / ml, and python3 is nothing but hassle. The resistance in my community, imo, is we got a medium pain (print vs print() isn't a hassle / dict.iteritems -> dict.items is a tiny pain, but dealing with years of split libraries and parallel installs and all that was a giant pita) with no benefits at all. Years later in 3.4 or 3.5 we finally got a matrix mult operator, but that's about it.
Yes, this is indeed a problem. You could argue the Macbook Pros also suffer from this. But at some point, you've got to make the changes. Since Python 3 was already a breaking change, is it better to suffer a bit more in the short term and lay the foundations for the future?
In a way, this trade-off of short-term vs long-term is what responsible people do every day. Brushing your teeth, going to college, etc. Sometimes the easy path is the wrong one. Most religions are fairly clear on this, too ;) But it does rely on a (perceived) gain in the future. For some people, Python 3 just isn't a great gain. And to be honest, it's only in later 3.* versions we've seen the really useful things. Even then, for some people Python 2 was enough, just like for some people bash is enough, or 640k or memory.
It's still a hard question, one with no definitive answer. Economically speaking, does one major port cost more than multiple breaking changes over time? You might think spreading the cost out is better, but this only works if reputation doesn't suffer. Which is, again, very hard to quantify.
But we're kind of past all of this. Python 2 is legacy, Python 3 is still actively developed. It isn't a discussion worth having, because it isn't a discussion anymore. Maybe next time (Python 4 anybody?), we can look back and learn something.
I just want people to know why it was changed, that there was some thought behind it, and that it wasn't arbitrary. Python Enhancement Proposals are easily my favourite "feature" of Python.
You're right, a print() statement is better than just print, but it was an unnecessary change, that was made 'for the best' without sufficient justification.
Unfortunately, historically, it seems that it would have been a far, far better choice to roll those fixes out incrementally, even if it meant multiple breaking changes.It was too many changes, all at once.
I think the lesson here is that time and time again, 'big bang' breaking changes have been failures.
2to3 should have made this a trivial change; but that only holds if 2to3 actually worked for every other simultaneous breaking change (it didn't).
A far, far more mature and better approach would have been the 3.x line being a continual stream of breaking changes with a flawless 2to3 that converted 100% of every python2 program to working python3, and a series of 3.xto3.y migrations that flawlessly upgraded python3 code until all breaking changes had been worked out.
Imagine if you had a series of transformations you could apply to any python2 project and you could incrementally migrate it automatically to 3.5. That is what we should have had. Screw print statements; invest in meaningful stuff when you make breaking changes.