Tim Peters wrote:
Sure is a lot of traffic on this -- can't we go back to hating the new license <wink>?
The license was withdrawn... I would prefer starting to talk about imputil.py.
[MAL]
Also, I don't know how "explicitly, long-windedly and straightforwardly" writing module imports is any different from using relative imports.
Hugely and profoundly different, as your example shows:
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.
Exactly: now instead of a bulletproof absolute import in a self-contained importer, whose precise meaning is clear from casual static inspection,
Ah, that's a new idea ! Package local absolute names... wow, that sounds weird.
you've got a relative one whose meaning depends vitally on where the importer happens to live. As code moves around, the import may fail to work when you're lucky, or pick up an unintended DateTime package when you're not. The semantics of the import are indeed relative now: you see the opportunity to type three additional characters <wink> as a strength, and I see nothing but headaches masquerading as convenience.
Tim, the intention was being able to move the mx level around, e.g. renaming it, eliminating it by sticking DateTime and ODBC under some other higher level package (yes, you'll have to watch out here because the higher level package might define DateTime and ODBC too -- but it's not all that likely), etc. The buzz word here is 'relocatable'.
As further consequence, simple "search-and-replace" strategies are rendered at best useless. That is, a simple grep can no longer find all & only references to mx's flavor of DateTime: it picks up all references to all DateTime guys, with no way short of a structure-aware tree crawler to sort them out again. Complexity spreads.
Of course, in the end, I lose no matter what. If *everyone* used dirt-dumb fully-qualified imports, all hassles with shifting package structure could be solved with a text editor in seconds. But that's not whiz-bang enough, so people *will* play endlessly dubious tricks with hooks, paths, relative imports, and metapackages too once Gordon gets around to them <wink>. Having an explicit way to spell relative imports would make my life easier because at least those are statically recognizable for what they are. I don't want them and won't use them, but it could ease the pain others will cause by using them. That's not enough to make me in favor of them, though; just enough so I won't pout if they do go in.
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!
Don't feel picked on, M-A! Opposition is normal and healthy; and the last idea I got anywhere with was list.pop().
Yah well. Last thing I succeeded with was making Python methods wrap any callable type. Seems that we're a bit too healthy (see MarkH's post) sometimes, i.e. there isn't all that much room for experiments. Just think of cool developments like Chris' stackless python. Experience shows that these kind of things will never make it into the distribution. Unfortunately, maintaing patches to the dist across releases a real pain and much work, so these ideas will just sit there unused and untested. Much the same happened to gcc ... in the end corporate strength made egcs possible. Perhaps we need such a branch too ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 106 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/