Changing the print is the most trivial part of the migration from py2 to py3, let's not make it a big deal.

I'm so extremely glad they got rid of the print statement. Was an ugly part of the language, and added keywords to python that didn't need to exist. I think they should get rid of the assert statement too and turn it into a builtin.

The print statement is/was a beautiful thing that dates to antiquity (e.g. Python 1 and BASIC), and one that many people loved. It was also used extensively.

Removing it (and breaking compatibility in general with no easy workarounds) is one of the major footguns in Python 3 that drastically slowed its adoption and basically forked the language.

It's a prime example of ideology trumping usability and practicality, resulting in the waste of probably millions of programmer hours, and orphaning millions of lines of code in Python 2 programs and libraries.

Other languages have managed to evolve effectively for decades without breaking backward compatibility; it's disappointing and embarrassing that Python simply hasn't.

History/preference aside, I think you’re being a bit hyperbolic regarding the cost of removing the print statement. It’s like the most trivial broken feature to fix with 2to3.

I’ve definitely run into issues 2to3 couldn’t automatically fix (encoding issues in some py2-only lib I needed to use IIRC), but upgrading print doesn’t really have much overhead.

You assume people know that 2to3 exists, and that they will all the time use it to fix copied code snippets. I think neither is true.

Python's print statement was surface-level beautiful, with subsurface flaws:

1) it modified the file object's "softspace"

  >>> class MyFile(object):
  ...   softspace = "Hello"
  ...   def write(self, s):
  ...     pass
  ...
  >>> f = MyFile()
  >>> f.softspace
  'Hello'
  >>> print >>f, "spam"
  >>> f.softspace
  0

2) This wasn't a problem until >> was added, because of problem #2 - the print statement didn't originally let you print to anything other than stdout. Which meant that if you wanted to support writing to a file instead of a stdout then you had to re-implement print yourself.

In practice, I've also found that having print as a function adds functionality because I can do things like:

    print(*data_values, sep="\n")

which is a quick way to print each value in a list on its own line.

"Readable" is in the eye of the beholder, which is why I commented that this was something I personally found useful, rather than one of the two subtle flaws I mentioned.

I can also disable all print statements with "def print(* args, * * kwargs): pass" at the top of the module.

I've had times where I couldn't figure out where a print was coming from, so I could replace print() to check the arguments passed in:

   import builtins
   builtin_print = builtins.print

   def my_print(*args, **kwargs):
      if "looking for" in args: # adjust as appropriate
         1/0
      return builtin_print(*args, **kwargs)

   builtins.print = my_print

Previously I had to do that by wrapping sys.stdout with my own file-like object, to intercept write(). (Granted, not hard, but harder.)

The fact that you can overwrite built-in functions is not a point in favor of the language. Imagine you do this in a library and everyone using print() in their project would use a modified print instead. You could've just modified sys.stdout instead.

Sure, but I never said I was doing this in library code. I mentioned I was using it to track down an unexpected print statement.

And the other example was in module scope.