Tim Peters wrote:
+ The notion that Python packages aren't self-contained now is wrong: a package module can import other modules in the package without qualification. This is good design.
Agreed. And we would like to take that notion one step further -- without breaking the two-scope resolution Python uses now. The '__' tags are just place holders which could just as well be handled by a simple Python fuction (like the one Gordon posted) using perfectly valid technology. Sticking this technology into the import statement is really only a more elegant approach. Nothing more. The whole thing already works using the current Python implementation.
+ JimF and MAL's shared notion that they're the only ones making significant use of packages is myopic.
Oh, c'mon Tim, we never did say that. We only mentioned having used package for quite a while. This includes having seen all the different pitfalls they have to offer.
Dragon also uses packages, and heavily, although products using them have not been announced and I can't talk about them yet. Anything I'm within 10 miles of doesn't use *any* import hooks, or play any other tricks on the system. Instead I urge people to write their imports as explicitly, long-windedly and straightforwardly as possible (with binding to a convenient local alias name on the following line). Do we embed sub-packages? Sure. Do modules move around in the hierarchy over time? Of course. So how do we deal with this supposed nightmare? Because all imports are relentlessly straightforward (even intra-package imports are fully qualified), and none are hiding in dynamic functions, we get into Emacs and do a global search-and-replace. Takes 30 seconds, and the new structure is plain as day to everyone reading the code.
This is perfectly ok if you're just using your own code, but it gets a mess when third-party packages are involved simply because you can't be sure they don't use import hooks, local imports or hacks to __path__ etc. If you still want them to be useable, you'll have to go down and dive into their structure. This takes time, is error prone and not necessarily fun. Also, I don't know how "explicitly, long-windedly and straightforwardly" writing module imports is any different from using relative imports. An example: mx .DateTime .ODBC.Windows In ODBC.Windows I would write: import __.__.DateTime which is just as explicit as writing import mx.DateTime except that the information about the top-level hierarchy is *not* included in the import information. Anyway, I'm not too inclined continuing this discussion anymore. I would never have thought that such a nifty little patch would have stirred up so much negative response. I'll just hack up my very own import mechanism using imputil and be done. So there! -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 107 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/