Guido van Rossum wrote: >> Real-world usage case for import __main__? Otherwise, I say screw it >> :) [...] My personal argument is that if __name__ == '__main__' is >> totally counter-intuitve and unpythonic. It also proves my memory: >> after many years, I still have to think a couple of seconds before >> rememebering whether I should use __file__, __name__ or __main__ and >> where to put the damn quotes. The fact that you're comparing a >> variable name and a string literal which seems very similar (both >> with the double underscore syntax) is totally confusing at best. >> >> Also, try teaching it to a beginner and he will go "huh wtf". To >> fully understand it, you must understand how import exactly works >> (that is, the fact that importing a module equals evaluating all of >> its statement one by one). A function called __main__ which is >> magically invoked by the python itself is much much easier to grasp. >> A different, clearer spelling for the if condition (like: "if not >> __imported__") would help as well. > > You need to watch your attitude, and try to present better arguments > than "I don't like it". Sorry for the attitude. I though I brought arguments against if __name__: - Harder to learn for beginners (requires deeper understanding of import workings) - Harder to remember (a string literal compared to a name with the same naming convention) - Often requires explicit sys.exit() which breaks python -i - Broken by -mpkg.mod, and we ended up with another __magic_name__ just because of this. - (new) Defining a main() function is already the preferred style for reusability, so __main__ would encourage the preferred style. If you believe that these arguments collapse to "I don't like it", then no, I don't have any arguments. -- Giovanni Bajo
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