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

[SourceForge.net]

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

>Category: Core (C code)
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
>Assigned to: Raymond Hettinger (rhettinger)
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)

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-09 09:53

Message:
Logged In: YES 
user_id=1038590

run_package_Py.diff attached, and a new version of execmodule.py

If it fails to find the module requested with '-m', it
reinterprets the command line from "python -m <script>" to
"python -m execmodule <script>".

One obscure issue is that a command line like "python
-mpychecker.checker" will overwrite the C-level argv[0] with
the path to execmodule.py, whereas "python -m
pychecker.checker" will leave it alone (the path to
execmodule.py is stored in argv[1] in the second case).

This may interact oddly with anyone using Py_GetArgcArgv to
get the *original* command line arguments.

One possibility is to just leave junk in sys.argv[0] when
running execmodule automatically (execmodule just deletes it
anyway).

I'm out of time for today, so I doubt I'll be able to get to
a C version before the beta release.

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-09 08:51

Message:
Logged In: YES 
user_id=1038590

execmodule.py attached.

You can experiment using "python -m execmodule <script>",
since I haven't written the C code to automatically hook
into this yet.

"from execmodule import execmodule" also has intriguing
possibilities. . .


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

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