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.

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.

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.

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 :-))

Logged In: YES 
user_id=113328

I can confirm that this has been fixed in 2.5a2