[Python-Dev] Release manager pronouncement needed: PEP 302 Fix

[Phillip J. Eby]

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.path_hooks 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.path_importer_cache 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).