[ python-Bugs-1250389 ] The -m option to python does not search zip files

SourceForge.net noreply at sourceforge.net
Thu Nov 10 11:26:34 CET 2005


Bugs item #1250389, was opened at 2005-08-02 17:55
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: The -m option to python does not search zip files

Initial Comment:
The -m option, to run a module from sys.path as a main 
program, does not work when the module is in a zip file. 
Here is an example demonstrating:

D:\Data>type zipmtest.py
def a():
    print "Hello, world"

if __name__ == '__main__':
    a()

D:\Data>python -m zipmtest
Hello, world

D:\Data>zip -9 zipm zipmtest.*
  adding: zipmtest.py (92 bytes security) (deflated 8%)

D:\Data>set PYTHONPATH=zipm.zip

D:\Data>del zipmtest.py
Deleting D:\Data\zipmtest.py
     1 file deleted

D:\Data>python -m zipmtest
python: module zipmtest not found

D:\Data>python -c "import zipmtest"

(note the last import - python can find the zipmtest 
module quite happily, but -m misses it).

This is a fairly severe limitation on -m, particularly as 
use of "egg" distributions (which are basically zipfiles) 
becomes more common.

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2005-11-10 10:26

Message:
Logged In: YES 
user_id=113328

I assume you meant PEP 338. I'm completely in favour of 
that. I didn't give feedback simply because I had nothing 
constructive to add beyond "+1"...

(And I agree that PEP 338 is more important than this bug - 
but I'd like to see both sorted :-))

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-11-10 09:05

Message:
Logged In: YES 
user_id=1038590

I agree this is a significant limitation on -m, although I
think it actually pales in comparison to the fact you can't
use modules inside packages.

So please take a look at PEP 328 and provide feedback on it.
I've had absolutely *zero* feedback on it since I wrote it,
and have had to assume that no-one else was bothered by the
current limitations.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2005-08-11 19:33

Message:
Logged In: YES 
user_id=113328

I have looked into this, and it appears that
_PyImportHooks_Init is getting called properly, and the
zipimport mechanism is getting initialised (python -v -m a
where a.py is in a zip file on sys.path shows this).

The problem seems to be that main.c calls, in Py_Main,
_PyImport_FindModule, with the "loader" argument set to
NULL, which disables handling of PEP 302 style import hooks.
This makes sense, to the extent that the current code needs
a real FILE* to call PyRun_AnyFileExFlags, it should be
possible (by calling PyRun_SimpleStringFlags instead,
maybe?) to execute a module loaded from a hook.

Unfortunately, I can't take this any further at present, as
I don't have the means to build Python in order to test a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470


More information about the Python-bugs-list mailing list