PEP 338: Executing modules inside packages with '-m'
Nick Coghlan
ncoghlan at iinet.net.au
Wed Dec 15 05:26:46 EST 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