PEP 338: Executing modules inside packages with '-m'

Nick Coghlan ncoghlan at iinet.net.au
Wed Dec 15 11:26:46 CET 2004


Martin Bless wrote:
> [Nick Coghlan <ncoghlan at iinet.net.au>]
> One thing I stumbled across with the current implementation:
> 
> Why doesn't "python -m abc" work with
> 
> ./abc/
> ./abc/__init__.py
> 
> assuming ./abc/ is directly on the path? In analogy to normal module
> import?

It doesn't work because abc is a package, rather than a module. There are lots 
of things that work as modules for import, but can't be used directly as scripts 
(builtin modules, C extension modules, packages, frozen modules, etc)

The command line "python ./abc" doesn't work, either - the closest you get is 
"python ./abc/__init__.py".

This is one of the things mentioned in the PEP - the restriction to Python 
source code or compiled bytecode is explicit, in order to match the existing 
command line behaviour. Even implementation of the PEP won't allow "python -m 
abc" to work.

However, with PEP 338, "pep -m abc.__init__" will actually try to run the 
package initialisation code as a script, simply due to the way imp.find_module 
works. Whether that does anything sane is up to the package author. Something to 
realise is that, in this case, __init__.py actually gets run twice - once for 
the package import, and then again as a script.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net



More information about the Python-list mailing list