On Sun, 01 Nov 2009 17:34:19 -0300, Gabriel Genellina wrote: > 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...).
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 -- http://mail.python.org/mailman/listinfo/python-list