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.