Imo c++ is terrible because of trying to maintain backwards compatibility too hard. Sure, keep abi and linking compatibility all you want but why should I be able to compile code written for c++98 in c++17 mode? No corporate policy would allow you to just flip the switch without thorough review and regression testing anyway. Removing features is also a feature. It would be better if you could compile each library in a different mode but still allow them to link to each other, this would allow you to gradually write code without the old crap in new libraries and still keep proven old code untouched.

The biggest mistake Python 3 made was the print statement change. There was really no compelling reason to do it, it broke basically 2.x script ever for 0 practical gain.

I'm not so sure. On one hand yeh sure, print vs print() may not have been something users were clamoring for, or worth adding an additional layer of confusion/weirdness over. However it's relatively straight-forward to port such code or instruct someone "ah you don't do print x you do print(x)".

From what I've seen the unicode/string bytes/chars is a much bigger factor. Ironically this change made my largest Python app easier in Python 3 (easier to embed unicode literals from various languages), so perhaps my opinion isn't so valid here...

Sure it's easy to fix, but it made a ton of scripts stop working despite being otherwise unaffected by the version change, all for the sake of a small syntax change. Unicode strings are a much bigger change and required some effort to fix, but it improved the language semantics while the print change rendered lots of scripts incompatible for no good reason. Just deprecating the old syntax and giving tons of warnings for a while before dropping it would have been much better.

I totally get you and I genuinely agree, it probably wasn't something so important to risk pissing people off over. As the sister comment to yours mentioned it could be seen as a bit of a "fuck you" to maintenance devs, but if we're honest with ourselves the reason that people haven't moved to Python 3.x after 7+ years isn't really due to print().

edit: sorry I hit "flag" instead of "parent" when trying to navigate back, hope that didn't affect anything (I've since unflagged)

Ultimately, I think Python 3 had exactly the wrong amount of breakage. They either should have broken way less (e.g., let 2.x code run largely unchanged if it didn't deal closely with unicode) or should have broken more, to give more of carrot... like if some of the new async stuff could have been available in 3.0, that would have given some people a reason to move right away.

I kind of feel like that's why print changed. It's going to be used in almost every Python script at some point in time, so it forces a breaking change without causing a seriously major break by itself. It's enough to make your script need to be updated, but not enough to make you re-write it from scratch (possibly in another language).

The unicode change was more impactful, but the print was more like a little fuck you to maintenance devs everywhere.

If they wanted print-as-function, fine, but they didn't have to eliminate the print statement at the same time.

Some warts you're better off not scratching at.

>> There was really no compelling reason to do it

> the print was more like a little fuck you to maintenance devs everywhere

> If they wanted print-as-function, fine, but they didn't have to eliminate the print statement at the same time.

Complete and utter hyperbole. You could read PEP-3105 [0] and easily see it isn't true. In addition to this, quoting from both the PEP and the docs [0][1]:

> "Luckily, as it is a statement in Python 2, print can be detected and replaced reliably and non-ambiguously by an automated tool, so there should be no major porting problems (provided someone writes the mentioned tool)."

> "When using the 2to3 source-to-source conversion tool, all print statements are automatically converted to print() function calls, so this is mostly a non-issue for larger projects."

Enough with the bullshit.

[0] https://www.python.org/dev/peps/pep-3105/ [1] https://docs.python.org/3/whatsnew/3.0.html

As much as I want Python 3 to replace Python 2, you can't recommend 2to3 while saying "Enough with the bullshit". 2to3 is abandonware that never worked.

Now you can use python-future instead, a third-party solution, but the 2to3 part of the PEP was a false promise that gave ammo to Python 2 fans.

> the 2to3 part of the PEP was a false promise that gave ammo to Python 2 fans

The PEP (3105) doesn't actually mention 2to3 anywhere, it just says that the fact that print is a statement (ie handled explicitly in the language syntax) means it is easy to write a tool to do the conversion automatically. Which is a perfectly valid point, even if 2to3 fails to do that for some reason.

At the end of day, if enough people beleive print requiring brakets is an issue, it's becoming an issue. I beleive it and few other people beleive it in this thread.

There is no added benefits to have done that. They are just not listening. Now, Pythons 2/3 are sufferin despite being one of best language out there.

> There is no added benefits to have done that.

For god's sake, it is subtle, but not that hard to understand. There are added benefits. For one thing, consistency. Why is `sys.stdin.write()` a function but `print` isn't? What happens if you want to replace `print` with your own function, e.g. for logging? With a print function, you can just reassign that function, with a statement, you can't. What's the effect of this switch on the bytecode/parsing code? All the arguments against it seem to come down to "I don't like it".

> being one of best language out there.

Why is Python one of the best languages out there? Ease of use through consistency. Surely that's just an argument for `print()`.

Python3 allowed the devs to fix some of the mistakes or sins of the past, similarly `input`/`raw_input`. In the short term, it's maybe a bit of hassle. In the long run, not at all. 2to3 handles this mostly, but you can use `from __future__ import print_function` to test it in Python2. Nobody is refusing to switch to Python3 because of `print` alone.

No one is against making print a function, we are just disappointed against the mandatory bracket thing. It's exactly what's wrong, you are not understanding because you don't want to listen. I agree with all the arguments you are presenting, but why can't you see why having to add - mandatory - brackets can be annoying?

In addition, the hack is already there:

  Python 3.5.2 (default, Dec 2015, 13:05:11)
  [GCC 4.8.2] on linux
     print "hello"
  Traceback (most recent call last):
    File "python", line 1
      print "hello"
                  ^
  SyntaxError: Missing parentheses in call to 'print'

Why not just calling print? We can do it right now and it's requiring no changes to the 3.x parser.

Finally, the print stuff was one of the main reasons I pick Ruby over Python for my startup 5 years ago. I may be alone but I don't think so. And I think I make the right decision. Look at the some of the latest benchmarks Ruby vs Python. Python is now lagging strongly behind when it was ahead 5 years ago with 2.7. The 3.x branch keeps making weird decisions.

> we are just disappointed against the mandatory bracket thing. It's exactly what's wrong, you are not understanding because you don't want to listen.

It's not hard. This isn't some arbitrary bracket hate or love, it's how the language syntax works at it's core: statements (e.g. if, el, in) never have brackets, function invocation always has. Simple!

So what am I not understanding? That you are proposing some other syntax, e.g. function invocation without brackets? That you don't like breaking changes? That you'd keep everything as it was for sake of habit? Python 3 breaks Python 2 in many ways, but okay. Any other coherent arguments why `print` should remain a statement?

> Finally, the print stuff was one of the main reasons I pick Ruby over Python for my startup 5 years ago

There are enough things to not like about Python 3. But do not get me started on Ruby. A language that constantly breaks stuff between minor version numbers (1.8 -> 1.9, 1.9 -> 2.0, etc)? Way to undermine your own argument.

Edit: To append this infamous article about a Ruby migration 1.8.7 to 1.9.3 (http://www.darkridge.com/~jpr5/2012/10/03/ruby-1.8.7-1.9.3-m...), lest I be accused of Ruby bashing. Of course, the original article we're discussing mentions Ruby in the same breath with Python 3. Oh, the irony of trying to put down Python 3 by citing Ruby.

Ruby allowed you to write code that worked in every version from 1.8.6 to 2.4, a huge benefit when writing libraries during the transition phase.

Things like the parentheses in print was why the 2.7 branch was created -- allow the old to exist and make available some of the new features. Probably the biggest mistake there was not to make deprecation warnings on by default, to accentuate that it was a transitionary release. Then again, it's the same problem PHP has, with not wanting to warn that the old way of doing things is going away for various reasons.

In python, functions are called using parentheses, so "make print a function" implies "require parentheses in calls to print". It would be weird to create a special case for the "functions are called using parantheses" rule just for print.

So make it a function, but the only function with optional parentheses? And only in some cases?

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.

> It was too many changes, all at once.

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.

The concepts of "text" and "array of bytes" should have been separated from the beginning, as they're distinct enough concepts. It's good that they separated them in python 3 but unfortunate that it causes problems because code didn't explicitly distinguish these two concepts.

I'm not sure if there's a third way for software that is omnipresent as Python.

Usually you have libraries, etc. which might be developed or not. As technology progresses, you can't achieve 100% backwards compatibility... I mean it's an accident waiting to happen, it's not a case of if it's just a case of when and how.

Well no one wants to hear it, but PHP devs do a good job keeping BC breaks minimal.

PHP4 to PHP5 was almost as big of a deal as Python2 to Python3. In fact, while I have PHP5 code that can easily ported to PHP7 -- I still have PHP4 code that will be forever on PHP4.

Because of this, PHP developers strive to avoid this kind of large breakage. Instead it's a smooth stream of deprecation and removals/changes and really large changes (like native unicode strings) have been non-starters.

I might be misguided, but the last time I used PHP was over ten years ago, using PHP3, and we had to name the files my_file.php3 in order to use PHP3. That's the opposite of minimal breakage. On the other hand, my simple PHP3 scripts continue to work to this day, php3 extension and all!

That's just how your server was/is configured.

As far as languages go, it broke a lot.

Not that it shouldn't have (register_globals) but it was obvious they were learning on the job.

You can't run most PHP3 code nowadays without work.

It's more like after PHP 5 the community had learned that lesson, while python didn't have the chance yet.

Given that, I think the PHP community handled the split much better, with the FIG pushing hard for PHP 5.

I think the difference is that most of PHP install base was managed by third parties (hosting providers) and once you lobbied those you basically forced everyone to upgrade. With python most of the install base is proprietary, and thus more fragmented, which makes it much more complicated to lobby for an upgrade.