4 ms·

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in cal

Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes off feeling needlessly pedantic for the language.

whimsicalism 4y ago
I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?
- johnchristopher 4y ago
  > I disagree strongly with this take and it seems basically to be saying "better error messages are bad." I rather have something like this: > Use exit() or Ctrl-D (i.e. EOF) to exit > >>> Less pedantic, less passive agressive. Doesn't fake being nice to the user.
- sigmoid10 4y ago
  No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and forcing it into a function after so many years was a terrible retroactive design choice.
  - ywain 4y ago
    Meh, the print change was fairly trivial. You could backport the print function in Python 2 codebases, and updating existing print statements to use the function was easy to automate. String changing from bytes to Unicode was a lot more painful, in my experience.
    - jbay808 4y ago
      Unfortunately, it also had the effect of breaking language tutorials going all the way up to "hello world". A tough experience for new learners, who are least able to debug those simple errors. Back when Python 3 was first released, the error message was not so clear, either...
    - sigmoid10 4y ago
      That was just the surface. Even the Python Foundation knew that their 2to3 converter tool just wasn't sufficient and hat to delay the discontinuation of Python 2 for half a decade, because there was so much unportable code out there. In the end we had 12 years where the two languages lived side by side and my first job using Python had us use 2.7 for new projects due to library concerns despite 3 being around for more than 7 years already.
- mattgreenrocks 4y ago
  Orthodoxy has never been my strong suit. I have a pragmatic take on this if only because of Python's ease of throwing a script together and its non-technical userbase. Were it something that effects correctness I'd more fully support this break of backwards compat.
- akira2501 4y ago
  This is why I appreciate languages with a strict and non-strict mode. Let me make that choice. In particular, if the parser is intelligent enough to understand what I meant and is just throwing a syntax error to be pedantic, then let me control that. Needlessly taking choices away will always be a frustration.
  - justin_oaks 4y ago
    The downsides of having both strict and non-strict mode: - It is a maintenance burden on the compiler/interpreter writers to allow both modes - There may be unexpected behavior when you use code from two different sources; one that expects strict mode and the other expects non-strict mode - There may be interpersonal conflict when developers working together prefer one mode over another
Waterluvian 4y ago
Here’s a good overview of the details between the two: https://snarky.ca/why-print-became-a-function-in-python-3/ https://snarky.ca/why-print-became-a-function-in-python-3/ “Why don’t we just keep both?” probably has many answers. The overwhelming one for me is that if everyone’s doing the same thing two ways, then everyone has to learn all the esoterics about the print statement. “Why don’t you just do it for me?” is a cardinal sin for a runtime. And already exists in migration tools.
- mattgreenrocks 4y ago
  Being able to use it in higher-order functions is somewhat un-Pythonic but I can accept that as a reasonable use for it. Would still prefer that print the statement is deprecated but usable.
  - whimsicalism 4y ago
    I think composition is becoming increasingly more within pythonic idioms... it is well suited towards pythons usage as a high-level controller around low level libraries in other languages. see also: the recent addition of match semantics in python
remram 4y ago
The problem is that the older syntax had way more ad-hoc oddities than just the lack of parentheses. Having to support weirdo statements like `print "hello", "world" >> sys.stderr` complicates the parser a lot and creates ambiguities, especially if you try to have it be both be this special-case statement and be a function object. Is `print >> obj` a print call with redirection to the file-like `obj`? Or is it a operator call between those objects? What does `f = print` do, assign the function object or the result of calling print with no arguments?
derefr 4y ago
I don't believe that the problem was that "having two forms of print is nonoptimal"; I believe the point was instead to remove a parsing ambiguity, which in turn allowed a whole class of errors to be caught at load time that previously weren't; and allowed the syntax to be extended in other new ways that previously couldn't have been encoded as parse rules due to the ambiguity. While the Python3 lexer is specifically hacked up to recognize 'print' as a distinct lexeme — and to thereby emit an additional parser meta-instruction lexeme that triggers a special error-handling path in the parser if you then go on to make a syntax error per the newer uniform syntax — it doesn't actually know what you were trying to print. (That'd require a successful parse!) If the Python3 parser tried to do the compatible thing, that'd require ditching the uniform syntax altogether, and going back to the ambiguous parser. It's a bit like Error Correcting Codes — the uniform Python3 parser knows enough to know that you did something wrong, and is provided by the lexer enough context to guess what kind of failure it was; but it doesn't have enough information to "Do What I Mean", because that's a strictly-greater amount of information.
saila 4y ago
If you type `func "arg"`, you get a generic syntax error. If you type `print "arg"`, the syntax error is a bit more informative, but I wouldn't say that the compiler "understands" what you mean. It's just making a guess based on the fact that the previous token was "print". On the other hand, supporting a special call syntax just for print, which includes more than just parentheses, would be substantially more complex. And then Python code in the wild would be more inconsistent and there will be endless debates about `print <args>` versus `print(<args>)`.

whimsicalism 4y ago

I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?

johnchristopher 4y ago
> I disagree strongly with this take and it seems basically to be saying "better error messages are bad." I rather have something like this: > Use exit() or Ctrl-D (i.e. EOF) to exit > >>> Less pedantic, less passive agressive. Doesn't fake being nice to the user.
sigmoid10 4y ago
No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and forcing it into a function after so many years was a terrible retroactive design choice.
- ywain 4y ago
  Meh, the print change was fairly trivial. You could backport the print function in Python 2 codebases, and updating existing print statements to use the function was easy to automate. String changing from bytes to Unicode was a lot more painful, in my experience.
  - jbay808 4y ago
    Unfortunately, it also had the effect of breaking language tutorials going all the way up to "hello world". A tough experience for new learners, who are least able to debug those simple errors. Back when Python 3 was first released, the error message was not so clear, either...
  - sigmoid10 4y ago
    That was just the surface. Even the Python Foundation knew that their 2to3 converter tool just wasn't sufficient and hat to delay the discontinuation of Python 2 for half a decade, because there was so much unportable code out there. In the end we had 12 years where the two languages lived side by side and my first job using Python had us use 2.7 for new projects due to library concerns despite 3 being around for more than 7 years already.
mattgreenrocks 4y ago
Orthodoxy has never been my strong suit. I have a pragmatic take on this if only because of Python's ease of throwing a script together and its non-technical userbase. Were it something that effects correctness I'd more fully support this break of backwards compat.
akira2501 4y ago
This is why I appreciate languages with a strict and non-strict mode. Let me make that choice. In particular, if the parser is intelligent enough to understand what I meant and is just throwing a syntax error to be pedantic, then let me control that. Needlessly taking choices away will always be a frustration.
- justin_oaks 4y ago
  The downsides of having both strict and non-strict mode: - It is a maintenance burden on the compiler/interpreter writers to allow both modes - There may be unexpected behavior when you use code from two different sources; one that expects strict mode and the other expects non-strict mode - There may be interpersonal conflict when developers working together prefer one mode over another

Waterluvian 4y ago

Here’s a good overview of the details between the two: https://snarky.ca/why-print-became-a-function-in-python-3/ https://snarky.ca/why-print-became-a-function-in-python-3/ “Why don’t we just keep both?” probably has many answers. The overwhelming one for me is that if everyone’s doing the same thing two ways, then everyone has to learn all the esoterics about the print statement. “Why don’t you just do it for me?” is a cardinal sin for a runtime. And already exists in migration tools.

mattgreenrocks 4y ago
Being able to use it in higher-order functions is somewhat un-Pythonic but I can accept that as a reasonable use for it. Would still prefer that print the statement is deprecated but usable.
- whimsicalism 4y ago
  I think composition is becoming increasingly more within pythonic idioms... it is well suited towards pythons usage as a high-level controller around low level libraries in other languages. see also: the recent addition of match semantics in python

remram 4y ago

The problem is that the older syntax had way more ad-hoc oddities than just the lack of parentheses. Having to support weirdo statements like `print "hello", "world" >> sys.stderr` complicates the parser a lot and creates ambiguities, especially if you try to have it be both be this special-case statement and be a function object. Is `print >> obj` a print call with redirection to the file-like `obj`? Or is it a operator call between those objects? What does `f = print` do, assign the function object or the result of calling print with no arguments?

derefr 4y ago

I don't believe that the problem was that "having two forms of print is nonoptimal"; I believe the point was instead to remove a parsing ambiguity, which in turn allowed a whole class of errors to be caught at load time that previously weren't; and allowed the syntax to be extended in other new ways that previously couldn't have been encoded as parse rules due to the ambiguity. While the Python3 lexer is specifically hacked up to recognize 'print' as a distinct lexeme — and to thereby emit an additional parser meta-instruction lexeme that triggers a special error-handling path in the parser if you then go on to make a syntax error per the newer uniform syntax — it doesn't actually know what you were trying to print. (That'd require a successful parse!) If the Python3 parser tried to do the compatible thing, that'd require ditching the uniform syntax altogether, and going back to the ambiguous parser. It's a bit like Error Correcting Codes — the uniform Python3 parser knows enough to know that you did something wrong, and is provided by the lexer enough context to guess what kind of failure it was; but it doesn't have enough information to "Do What I Mean", because that's a strictly-greater amount of information.

saila 4y ago

If you type `func "arg"`, you get a generic syntax error. If you type `print "arg"`, the syntax error is a bit more informative, but I wouldn't say that the compiler "understands" what you mean. It's just making a guess based on the fact that the previous token was "print". On the other hand, supporting a special call syntax just for print, which includes more than just parentheses, would be substantially more complex. And then Python code in the wild would be more inconsistent and there will be endless debates about `print <args>` versus `print(<args>)`.