On Sun, Oct 3, 2021 at 4:18 AM Paul Bryan <pbryan@anode.ca> wrote:
Thanks for finding that.
While I don't feel strongly one way or the other, I do think the discussion is worthwhile.
As I understand, the arguments for: - let's get rid of boilerplate, that many (esp. beginners) may not understand
It's not really boilerplate. The idiom exists for situations where one block of code needs to be able to do two different things (or needs to do something or not do that something) based on some run-time condition. It is, exactly and perfectly, the job of an if statement.
- you could add command line arguments and return values in a more natural way
As I understand, the arguments against: - it's just 2 lines of code; this isn't a big problem being solved - boilerplate serves to teach a fundamental concept about the loading and execution of Python modules
This is more important than you might think. It's a reminder that, unlike in some languages, top-level Python code is just code. It executes from the top down, and it can do things at the points that it comes to them. This is a much bigger deal than a lot of beginners realise, and I don't see any value in hiding that behind something that encourages an idiom of "write everything in functions, one function is magically called, and then everything happens".
- there may not be a clean way to maintain compatibility with previous versions of Python
The way to maintain compatibility is... don't use the new idiom. If you need your code to run on older Pythons, keep using the if-name-is-main idiom. I don't think the backward compatibility break of giving meaning to a dunder name is particularly significant; dunder names are special, so if you've been writing "if __name__ == '__main__': __main__()", then you're opening yourself up to problems anyway (just call it main() and be done with it). ChrisA