evaluation question

[Chris Angelico]

On Wed, 1 Feb 2023 at 10:47, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.

"Soft space" (the trailing comma behaviour) was an incredibly complex
wart. Glad it's gone.

> Also, introducing a paren-less call syntax would be a very big
> and controversial change that would be way out of proportion to
> the problem.

Oddly enough, that WAS actually proposed recently - by Guido himself -
as a demonstration of the power of the new PEG parser:

https://mail.python.org/archives/list/python-ideas@python.org/thread/NCQX6ZIBREUTLS52VVG3DSZ43OEXJFTT/

(The mailing list archive messes up formatting a bit with REPL
transcripts, thinking they're quoted text.)

The general consensus was "allowing function calls without parens
causes more issues than it solves", with plenty of examples from other
programming languages to prove this - Ruby, while generally a decent
language, shows a rather nasty wart with this particular feature (see
"Ruby allows parens-less function calls" from Steven D'Aprano in that
thread). I don't think it'll ever happen in Python, but it's nice to
know that the parser is flexible enough. It means that other weird
cases, where the intuitive expectation is different, can be better
handled (see eg "with (x as y, a as b):" syntax).

Having print as a function is WAY better than having it as a special
case with lots of warts. And it's so much easier to add extra features
to it; for instance, how would you add a "flush after printing" flag
to Py2's print statement? With a function, it's easy - just print(...,
flush=True).

ChrisA