[Python-Dev] Issue 4195: Can't execute packages with -m inPython 2.6/3.0
python at rcn.com
Sat Nov 22 05:40:14 CET 2008
In concur that it is not a regression (esp for Py2.6).
OTOH, it would be nice to have -m run as expected.
It seems reasonable to me to get this working for 3.0.
----- Original Message -----
From: "Guido van Rossum" <guido at python.org>
To: "Lisandro Dalcin" <dalcinl at gmail.com>
Cc: "Nick Coghlan" <ncoghlan at gmail.com>; "Python Dev" <python-dev at python.org>
Sent: Friday, November 21, 2008 7:16 PM
Subject: Re: [Python-Dev] Issue 4195: Can't execute packages with -m inPython 2.6/3.0
I don't think that removing an unintentional and subtly broken feature
is a regression.
On Fri, Nov 21, 2008 at 7:04 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> Unless this is considered a regression...
> On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <guido at python.org> wrote:
>> I think it crosses the line.
>> On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> I need a release manager call on whether or not the proposed resolution
>>> of this issue goes beyond what is acceptable for a bug fix in 2.6.1.
>>> Short version:
>>> - Python 2.5 allowed packages to be executed with -m, but in a broken way
>>> - I disabled the broken way for 2.6, but didn't provide a replacement
>>> - The patch attached to 4195 once again allows execution of packages
>>> with -m, but in a clean way similar to the way directories and zipfiles
>>> can now be executed
>>> - I would like to commit that patch for 3.0/2.6.1, but I'm concerned
>>> that it crosses the "no new features" line
>>> Long version:
>>> There was a bug in python 2.5 that allowed a package name to be passed
>>> to the -m switch or runpy.run_module() and it would mostly work.
>>> However, the 'mostly' was due to the fact that doing this put the
>>> internal import machinery into a slightly inconsistent state: the
>>> interpreter was running code from inside a package, but that package
>>> wasn't actually present in sys.modules. This could lead to assorted hard
>>> to trace import-related weirdness, similar to what you can get when
>>> executing a file from inside a package by name. You would often get away
>>> with it, but good luck figuring out what is happening if things go wrong
>>> (and you aren't already an expert on Python import mechanics).
>>> Since the ability to execute packages wasn't intentional, I added the
>>> missing check to block it explicitly in 2.6 (but left it alone for 2.5).
>>> It seemed like a really niche feature, so I didn't figure out a clean
>>> replacement for it at the time.
>>> Benjamin noticed this change earlier in the 2.6 release cycle, I pointed
>>> out it was a deliberate change, and that's the way it stayed until after
>>> 2.6 was released.
>>> After the release, Andi Vajda (from the JCC project ) contacted me,
>>> and together we worked out a better implementation of package support
>>> for the -m switch (and runpy.run_module)  by extending the
>>> __main__.py approach used to support direct execution of zipfiles and
>>> directories .
>>> That's what I would like to add, since it nicely complements the ability
>>> to execute zipfiles and directories, while also restoring the ability to
>>> pass a package name to the -m switch (but in a way that keeps the import
>>> machinery in a consistent state).
>>>  http://pypi.python.org/pypi/JCC
>>>  http://bugs.python.org/issue4195 (package execution with -m)
>>>  http://bugs.python.org/issue1739468 (zipfile execution)
>>> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>> Python-Dev mailing list
>> Python-Dev at python.org
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
> Lisandro Dalcín
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
--Guido van Rossum (home page: http://www.python.org/~guido/)
Python-Dev mailing list
Python-Dev at python.org
More information about the Python-Dev