On Wed, 1 Feb 2023 at 10:47, Greg Ewing <greg.ew...@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-id...@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 -- https://mail.python.org/mailman/listinfo/python-list
