5 ms·

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 the

by typon 6y ago

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.

musicale 6y ago
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.
- rsfern 6y ago
  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.
  - mafuy 6y ago
    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.
- eesmith 6y ago
  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.
  - Grue3 6y ago
    for v in data_values: print v Is exactly the same length but much more readable.
    - eesmith 6y ago
      "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.)
      - Grue3 6y ago
        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.
        eesmith 6y ago
        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.

by typon 6y ago

musicale 6y ago

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.

rsfern 6y ago
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.
- mafuy 6y ago
  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.
eesmith 6y ago
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.
- Grue3 6y ago
  for v in data_values: print v Is exactly the same length but much more readable.
  - eesmith 6y ago
    "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.)
    - Grue3 6y ago
      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.
      - eesmith 6y ago
        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.