[Patches] [ python-Patches-1043356 ] Enhancing '-m' to support packages

SourceForge.net noreply at sourceforge.net
Fri Oct 8 23:44:01 CEST 2004


Patches item #1043356, was opened at 2004-10-09 07:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043356&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancing '-m' to support packages

Initial Comment:
Thomas Heller posted "python -m pychecker.checker
<script>' as an example where it is worthwhile to allow
execution of a script inside a package. This seems like
a compelling use case to me (making pychecker easy to
run is enough of a PITA that I confess I often don't
run it), and I'm sure there are other examples.

The only semantics that I can see working for packages
are the following:

python -m pychecker.checker

is equivalent to:

python execchecker.py

where execchecker.py is:

import sys, imp
import pychecker
info = imp.find_module("checker", pychecker.__path__)
sys.argv[0] = info[1]
execfile(info[0])

We *have* to do the import of the requested script's
containing package - otherwise, we can't obey Python's
packaging rules with respect to the use of __path__.

I will attach two versions.

The first will, when it fails to find a module for
itself, switch to executing something like "-m
execmodule". 'execmodule.py' would be a new stdlib
module to handle the above behaviour (initially not
providing any useful interfaces when directly
imported). Guido was certainly right when he said this
will be easier to enhance if written in Python - I
think this way (going to Python when it isn't a
top-level module) gives us the best of both worlds.

The second version will be pure C. The reason I'm going
to do that, is I expect the idea of adding a standard
library module for this to be controversial, especially
given the proximity to 2.4beta1. (I hope I'm wrong,
since I think the Python-C hybrid is a more flexible
solution, which can also be leveraged by other
interpreter implementations)

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

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


More information about the Patches mailing list