[Guido van Rossum] > [...] print is the only application-level functionality that has a > statement dedicated to it. Within Python's world, syntax is generally > used as a last resort, when something *can't* be done without help > from the compiler. Print doesn't qualify for such an exception (quite > the opposite actually). As I much liked Pascal in its time, `write()' and `writeln()' are nothing awkward to me, yet in Pascal, neither was a "regular" function, and the Pascal compiler had special code for parsing these two. Python functions are designed in such a way that `write()' and `writeln()' in Python could be just functions, with no special compiler stunt, and consequently, they fit even better for Python than they did for Pascal. Let's consider that `print' (or whatever) is a Python function, not negotiable. It should likely be. If people resent the parentheses that a new `print' would impose, then it might mean they would like that there is to be some way so Python functions could be be callable without parentheses in a more general way. It would represent quite a change in the syntax, and pull with it its own flurry of problems; but nevertheless, a seek for such a change might be presented as the only way for introducing `print' in Python 3K without a need for parentheses. Perl, going from version 4 to version 5, was subject to a cleanup between operators and functions which could be seen as similarly encompassing. Logo and a few others also have parentheses-less function calls, yet they may be week at handling functions as first-class objects. (And besides, I'm far from overly liking them! :-). -- François Pinard http://pinard.progiciels-bpi.ca
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4