[Python-Dev] Release manager pronouncement needed: PEP 302 Fix (original) (raw)
Phillip J. Eby pje at telecommunity.com
Thu Jul 27 17:58:15 CEST 2006
- Previous message: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
- Next message: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote:
Armin Rigo wrote: > Hi Phillip, > > On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote: >> If we don't revert it, there are two ways to fix it. One is to just change >> PEP 302 so that the behavior is unbroken by definition. :) The other is >> to actually go ahead and fix it by adding PathImporter and NullImporter >> types to import.c, along with a factory function on sys.pathhooks to >> create them. (This would've been the PEP-compliant way to implement the >> need-for-speed patch.) >> >> So, "fix" by documentation, fix by fixing, or fix by reverting? Which >> should it be? > > "fix" by changing the definition looks like a bad idea to me. The > import logic is already extremely complicated and delicate, any change > to it is bound to break some code somewhere.
Though beta1 and beta2 shipped with this change nobody reported any bug that could be linked to it.
Because in at least setuptools' case, you have to be using unzipped namespace packages under the right set of circumstances to trigger a propblem.
sys.pathimportercache is quite an internal thing
Whose behavior is documented in a PEP.
and most code, even import hooks, shouldn't have to deal with it.
That doesn't make it unimportant. It's a visible change in specified behavior between Python versions -- precisely the sort of thing that makes people mad at us renegade cowboy Python-dev hackers changing their language for no apparent reason. The strftime thing that recently got hashed to death here was also an "internal thing" which "most code shouldn't have to deal with".
This is precisely how these kinds of problems happen.
So, this needs to either be documented in the What's New document and PEP 302 at a minimum, or it needs to be reverted, unless somebody wants to bless the feature addition to fix it.
I'm willing to write code that makes it PEP 302 compliant, if the release manager will bless such an addition. But if that's not acceptable, then somebody needs to produce the necessary documentation updates or revert the patch. It absolutely should not be allowed to remain in and undocumented because it is a backwards-incompatible change to documented behavior of Python for two major releases (2.3 and 2.4).
- Previous message: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
- Next message: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]