On Sat, Oct 02, 2021 at 05:13:01PM +0100, Alex Waygood wrote:
> I disagree that "it teaches a lot about how Python works" is a good
> reason to keep things the way they are. If you applied this principle
> more broadly, it would seem to be an argument in favour of complexity
> in most situations, that would imply we should keep syntactic sugar to
> a bare minimum at all times.
Not necessarily the bare minimum (which is a subjective judgement), but
yes, we should keep the amount of syntactic sugar low.
Syntactic sugar that has clear benefits is a win.
For example, decorator syntax is syntactic sugar that has been a great
win for the language because it makes it easier to use and read a
powerful design pattern, the Decorator Pattern. Comprehensions have been
a great win for the language because they have allowed us to simplify
something which was a minimum of three statements into a single
expression.
`yield from` is syntactic sugar for something which requires a
complicated, nested set of multiple try...except blocks and for loops to
do correctly. (See the PEP for details.)
These have all been examples of good syntactic sugar.
Syntactic sugar without such benefits will just rot your teeth :-)
Whereas this is, *at best*, a trivial benefit (save two lines). It
doesn't make it easier to do something hard and complicated (like yield
from) or avoid violating DRY (like decorator syntax), or do something
previously impossible (write an explicit loop as an expression). It
doesn't simply your code, or make it easier to write scripts, or do
anything that can't already be trivially done, or make your scripts
safer. It just replaces one trivial piece of one-line boilerplate:
if __name__ == '__main__':
with another piece of boilerplate:
def __main__():
Yay for progress! We save eleven whole characters, which at current hard
drive costs is a saving of approximately 0.00000004 cents :-)
(I know, I know, this proposal is not really about saving storage space,
but people have mentioned saving typing.)
Any way we look at it, this is not going to transform Python programming
like decorator syntax, comprehensions or async have. At best all it is
going to do is shift one trivial idiom to another trivial idiom, but at
a cost of:
- obsoleting masses of documentation (tutorials, walk-throughs, videos,
demos, example code, blog posts, Stackoverflow answers etc) that
recommend the `if __name__ ...` idiom;
- add a *long* transition period (maybe forever!) where people,
especially newbies, are unsure which idiom is better and whether to use
the old or new version;
- yet another thing that has to be programmed into the interpreter,
tests written and run, and documented.
You might argue that the costs are trivially small, but the benefits are
correspondingly even smaller.
> Learning about how Python works under the hood is extremely valuable
> for becoming a more advanced programmer. However, not everybody needs
> to be a mechanic to drive a car. We should surely make it as easy as
> possible for beginners to write fully functional scripts that conform
> to best practices.
Stuffing everything in a main() function just for the sake of having it
in a main() function is not "best practices", it is cargo-cult
programming.
Right now, the best practice Hello World program in Python is:
print("Hello world!")
which is as simple and newbie-friendly as it is possible to get. This
alleged "best practice" is not:
def main():
print("Hello world!")
__main__(main)
or any of the other variants involving decorators, special builtins,
sys.run_main(), special dunder names, magical implicit behaviour etc.
> I love this proposal. "if__name__ == '__main__'" has always felt, to
> me, as though it flies in the face of the simplicity and elegance
> Python generally prizes in other parts of the language.
I can't imagine why you think that. Let's run through the Zen:
**Beautiful is better than ugly.** That's subjective, and some people
think dunders are ugly. Maybe so, but they are ubiquitous in Python.
**Explicit is better than implicit.** The current idiom is explicit.
**Simple is better than complex.** And simple.
**Readability counts.** And readable.
**Special cases aren't special enough to break the rules.** The special
case of a script main function isn't special enough to be treated as a
special case.
**There should be one-- and preferably only one --obvious way to do it.**
For 30 years, that one obvious way has been `if __name__ == ...`.
**If the implementation is easy to explain, it may be a good idea.** The
implementation is certainly easy. It's just an `if`, like every other if
in the language. The trickiest part is that the interpreter has to set
the global variable `__name__` to a string, and that's not even a
little bit tricky.
So out of the 19 koans in the Zen, six support the current idiom, one is
*just maybe* negative, and the rest are neutral.
_______________________________________________
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/GH5A4RGLM76BSTZ2N4MHPJ6KM4V7J5AL/
Code of Conduct: http://python.org/psf/codeofconduct/
