import bug

[Steven D'Aprano]

On Sun, 01 Nov 2009 17:34:19 -0300, Gabriel Genellina wrote:

> En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano
> <steve at remove-this-cybersource.com.au> escribió:
>> On Sun, 01 Nov 2009 01:38:16 -0300, Gabriel Genellina wrote:
> 
>>>> Incorrect. Simplicity of implementation and API is a virtue, in and
>>>> of itself. The existing module machinery is quite simple to
>>>> understand, use and maintain.
>>>
>>> Uhm... module objects might be quite simple to understand, but module
>>> handling is everything but simple! (simplicity of implem...? quite
>>> simple to WHAT? ROTFLOL!!!  )
>>
>> I stand corrected :)
>> Nevertheless, the API is simple: the first time you "import name",
>> Python searches a single namespace (the path) for a module called name.
>> There are other variants of import, but the basics remain:
>>
>> search the path for the module called name, and do something with the
>> first one you find.
> 
> Sure, beautiful, a plain and simple search over a list of directories.
> That's how it worked in Python 1.4, I think... Now you have lots of
> "hooks" and even "meta-hooks": sys.meta_path, sys.path_hooks,
> sys.path_importer_cache. And sys.path, of course, which may contain
> other things apart of directory names (zip files, eggs, and even
> instances of custom "loader" objects...). 

You'll notice I deliberately didn't refer to directories. I just said 
"the path". If the path contains things other than directories, they are 
searched too.


> PEP 302 explains this but I'm
> not sure the description is still current. PEP369, if approved, would
> add even more hooks.
> Add packages to the picture, including relative imports and __path__[]
> processing, and it becomes increasingly harder to explain. Bret Cannon
> has rewritten the import system in pure Python (importlib) for 3.1; this
> should help to understand it, I hope. The whole system works, yes, but
> looks to me more like a collection of patches over patches than a
> coherent system. Perhaps this is due to the way it evolved.

You've convinced me that the implementation of the import infrastructure 
isn't as clean as I imagined. I'm sure it's a gnarly hack on top of 
gnarly hacks, and that maintaining it requires heroic measures worthy of 
a medal *grin*. 


>>>> Dealing with name clashes doesn't come for free. If you think it
>>>> does, I encourage you to write a patch implementing the behaviour you
>>>> would prefer.
>>>
>>> I'd say it is really a bug, and has existed for a long time.
>>
>> Since import is advertised to return the first module with the given
>> name it finds, I don't see it as a bug even if it doesn't do what the
>> programmer intended it to do. [...] Shadowing a standard library module
>> is no different.
> 
> But that's what namespaces are for; if the standard library had its own
> namespace, such collisions would not occur. 


Sure. But that's not a bug in the import system. If it's a bug, it's a 
bug in the layout of the standard library.


>> You could do it in a backwards compatible way, by adding the std
>> package directory into the path.
> 
> Unfortunately you can't, at least not without some special treatment of
> the std package. One of the undocumented rules of the import system is
> that you must not have more than one way to refer to the same module (in
> this case, std.re and re). 

*slaps head*

How obvious in hindsight.



-- 
Steven