En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano
<st...@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
--
http://mail.python.org/mailman/listinfo/python-list
