Add a -z interpreter flag to execute a zip file
Andy C wrote:
... a .zip file with a __zipmain__.py module at its root?
Why not just an __init__.py, which you would normally execute if you tried to import/run a directory?
* Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__.
Treating zip files (and only zip files) as a special case equivalent to uncompressed files seems like a wart; I would prefer not to special-case zips any more than they already are. If anything, I would like to see the -m option enhanced so that if it gets a recognized "collection" file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. [on using __main__ instead of __init__ or __zipmain__]
__main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop?
It doesn't today; it does use circular imports, which can be a problem.
while I think it would be a bad practice to import __main__,
I have seen it recommended as the right place to store global (cross-module) settings. -jJ
Jim Jewett wrote:
If anything, I would like to see the -m option enhanced so that if it gets a recognized "collection" file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure.
-m deals with the package namespace as it already stands - it knows nothing whatsoever about the underlying filesystem (and that's deliberate - the runpy module relies on PEP 302 to abstract away all those details). On Phillip's idea regarding being able to execute directories and zip files, I think the semantics would actually be manageable (as directories and zip files can be definitely identified), but I'd be concerned as to the startup cost for checking what is being executed. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
At 03:28 AM 7/15/2007 +1000, Nick Coghlan wrote:
Jim Jewett wrote:
If anything, I would like to see the -m option enhanced so that if it gets a recognized "collection" file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure.
-m deals with the package namespace as it already stands - it knows nothing whatsoever about the underlying filesystem (and that's deliberate - the runpy module relies on PEP 302 to abstract away all those details).
On Phillip's idea regarding being able to execute directories and zip files, I think the semantics would actually be manageable (as directories and zip files can be definitely identified), but I'd be concerned as to the startup cost for checking what is being executed.
Well, the start file is being opened and checked for directory-ness already, and it has to be read to be executed. The extra reading to see if it's a zipfile isn't likely to be much additional overhead. At this point I've got a partial patch. It figures out when it should import __main__, but it's not successful at actually doing so. It seems that simply importing or reloading '__main__' doesn't work, because it's considered a built-in module. Apparently, I'll have to explicitly load the module via the found importer.
On 7/13/07, Jim Jewett <jimjjewett@gmail.com> wrote:
Andy C wrote:
... a .zip file with a __zipmain__.py module at its root?
Why not just an __init__.py, which you would normally execute if you tried to import/run a directory?
* Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__.
Treating zip files (and only zip files) as a special case equivalent to uncompressed files seems like a wart; I would prefer not to special-case zips any more than they already are.
Just to clarify, my patch already works with uncompressed directory trees just fine. It's just a matter of naming, I suppose. I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different.
while I think it would be a bad practice to import __main__,
I have seen it recommended as the right place to store global (cross-module) settings.
Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think. Andy
On Saturday 14 July 2007, Andy C wrote:
I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different.
We could use -r ("run"), or -X ("execute"); not sure those are really right either.
while I think it would be a bad practice to import __main__,
I have seen it recommended as the right place to store global (cross-module) settings.
Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think.
I've seen __main__ suggested as a place to store application-specific global settings, but not for a long time. I don't think it was ever mapped directly to a file on disk though. I find the idea really hackish. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
On 7/14/07, Andy C <andychup@gmail.com> wrote:
On 7/13/07, Jim Jewett <jimjjewett@gmail.com> wrote:
while I think it would be a bad practice to import __main__,
I have seen it recommended as the right place to store global (cross-module) settings.
Where? People use __main__.py now?
No; they don't use a file. It is treated as a strictly dynamic scratchpad, and they do things like import __main__ __main__.DEBUGLEVEL=5 if __main__.myvar: ... -jJ
participants (5)
-
Andy C -
Fred L. Drake, Jr. -
Jim Jewett -
Nick Coghlan -
Phillip J. Eby