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 <[EMAIL PROTECTED]> wrote: > Unless this is considered a regression... > > On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> I think it crosses the line. >> >> On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> 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 [1]) contacted me, >>> and together we worked out a better implementation of package support >>> for the -m switch (and runpy.run_module) [2] by extending the >>> __main__.py approach used to support direct execution of zipfiles and >>> directories [3]. >>> >>> 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). >>> >>> Cheers, >>> Nick. >>> >>> [1] http://pypi.python.org/pypi/JCC >>> >>> [2] http://bugs.python.org/issue4195 (package execution with -m) >>> [3] http://bugs.python.org/issue1739468 (zipfile execution) >>> >>> -- >>> Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia >>> --------------------------------------------------------------- >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev@python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> 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@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
