At 09:13 PM 7/12/2007 -0700, Andy C wrote:
I can definitely see why it "just makes sense", and my first thought was indeed to name it __main__. But then you lose the ability to make a distinction: What does "if __name__ == '__main__" mean in __main__.py? : )
The same as anywhere else; it'll just always be true. :)
If someone tries does import __main__ from another module in the program, won't that result in an infinite loop?
No, for two reasons. First, importing __main__ always returns whatever the start script is using as a __main__ module. Second, even if you're in the middle of __main__ itself, the module is already in sys.modules. So this is a non-issue.
At Google some people do "import sitecustomize" and get values that were computed earlier by the sitecustomize. I could see the same kind of thing happen with __main__.py.
Yes, but it won't work unless the overall program was launched via that particular __main__.py -- running from the interpreter prompt for example, those values won't be there. So, people will learn quickly why that doesn't work.
Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as).
Where would you do that? Just typing it literally on the command line?
Yes.
I think it's sufficient to treat it as a documented "trick" that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases.
Eh? First you say there aren't any use cases, now you say there'll be too many? I'm confused. The only competing proposal besides what I've suggested was the one to add an option to "runpy", and IMO that's dead in the water due to shebang argument limits.
As implemented the patch is fairly simple, and shouldn't have any unintended consequences. I'm not necessarily opposed to making it more general and thinking about sys.path vs. a zip file specifically.
I think it can be replaced with using standard importer detection of sys.argv[0], to decide whether it is an importable location (dir/zip), and then importing __main__, with fallback to the old script behavior. This is forward-compatible with other import mechanisms, and supports #! lines better for zipfiles, since no -z option is needed.