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

[Bob Ippolito]

On Jul 27, 2006, at 3:52 AM, 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. sys.path_importer_cache is quite an internal  
> thing and
> most code, even import hooks, shouldn't have to deal with it.

Anyone trying to emulate what imp.find_module does in a PEP 302  
compliant way will need to introspect sys.path_importer_cache. I have  
some unreleased code based on the PEP 302 spec that does this and the  
way it was originally written would have broke in 2.5 if I had tested  
it there.

Just because it's obscure doesn't mean we should go change how things  
work in a way that's not consistent with the documentation. The  
documentation should change to match the code or vice versa, though I  
really don't have any strong feelings one way or the other.

-bob