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
--
http://mail.python.org/mailman/listinfo/python-list
