import bug

[Steven D'Aprano]

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.


>> 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. If I do this:

>>> len = 1
>>> def parrot(s):
...     print len(s)
...
>>> parrot("spam spam spam")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in parrot
TypeError: 'int' object is not callable


it isn't a bug in Python that I have misunderstood scopes and 
inadvertently shadowed a builtin. Shadowing a standard library module is 
no different.


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



-- 
Steven