On Tue, Jun 9, 2020 at 5:49 PM Naomi Ceder <naomi.ce...@gmail.com> wrote:
> FWIW... > > As someone who has spent at least the last 5 years trying (unsuccessfully) > to reprogram 15 years of muscle memory of print as a statement, I vote +1 > to print without parens. > > As someone who teaches Python and groans at explaining exceptions, I'm -0 > on print without parens and -1 on other calls without parens. > -1 overall for me... even though I *liked* the Python 0-2 print statement syntax for being "different" and readable without the need for shift-key-awkwardness of ()s including the shell like use of >>sys.stderr up front to redirect the output. This "difference" excused it from auto-inserting magic spaces between everything and repurposing >> - it was "special". Today's function though, it just fits in better with the overall language. It is consistent. It is obviously a function the likes of which anyone could define. As soon as callables can magically be called using a space instead of ()s a whole new world of typos and misunderstandings of what is what and what belongs with what comes up. Modifications to code that need to change calling formats require more complicated edits, etc. I realize that many other high level languages feature this kind of "treat a callable as a command" syntax. But I've never felt it was consistent as it was purely a style choice which syntax to use and when, so why cause conflict and require that decision? Useful for small scripting mentality, but not while programming and engineering reusable maintainable code. In large Perl code bases of yore, the style norm was to not use this style of call or if used, limit it solely to built-ins. We've got one way of doing things that people understand and works, why do we need yet another? We aren't Perl, Ruby, Rexx, Lua, Tcl, ... I love that the new parser allows us to even explore these possibilities. We should be very cautious about what syntax changes we actually adopt. -gps
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7FQDT3KTVRWP7SQ5FMB77R6OXLO5SXHL/ Code of Conduct: http://python.org/psf/codeofconduct/
