import bug

[Gabriel Genellina]

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

>>> 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. I can think of C++, Java, C#,  
all of them have some way of qualifying names. Python too - packages. But  
nobody came with a method to apply packages to the standard library in a  
backwards compatible way. Perhaps those name collisions are not considered  
serious. Perhaps every user module should live in packages and only the  
standard library has the privilege of using the global module namespace.
Both C++ and XML got namespaces late in their life so in principle this  
should be possible.

>> One way to
>> avoid name clashes would be to put the entire standard library under a
>> package; a program that wants the standard re module would write "import
>> std.re" instead of "import re", or something similar. Every time the std
>> package is suggested, the main argument against it is backwards
>> compatibility.
>
> 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). Suppose someone imports std.re; an entry in  
sys.modules with that name is created. Later someone imports re; as there  
is no entry in sys.modules with such name, the re module is imported  
again, resulting in two module instances, darkness, weeping and the  
gnashing of teeth :)
(I'm sure you know the problem: it's the same as when someone imports the  
main script as a module, and gets a different module instance because the  
"original" is called __main__ instead).

-- 
Gabriel Genellina