Guido van Rossum wrote:
I'm wasn't planning to write my own hook until now. I need this feature to be able to organize my package internal stuff swiftly and easily, plus to be able to possibly put it under new top-level packages. Obviously I seem to be more or less alone with this need, so I'll stop argueing for inclusion of "something like relative imports" in the distribution.
I still hope against hoping to convince you not to do this. I think this adds lots of complexity for the reader of your package. I think of *all* software that I write as something that eventually someone is going to read and try to understand. I also think of it as something that eventually someone is going to port to a platform that wasn't even designed when I wrote the software. Tricks like depending on a custom import hook make reading a pain.
For example, the reader who is just starting to browse a large package often needs to follow the thread of execution from one module to the next. If the import statements contain magic like __magic__.foo.bar (actually proposed magic renamed for generality :-), this reader will first need to understand the custom importer -- which is likely one of the hariest components of the package.
While it will perhaps look funny to him at first sight, I'm sure that a proper name will make the idea clear to him: from __superpackage__.foo import bar or just from __super__.foo import bar [Super Foo -- sounds like a comic star ... there's even integrated fun in these names ;-)]
The same thing applies with even more force to tools like package browsers. IDLE for example has a class browser which displays the true module and class name for base classes. E.g. if you have code that says
from Tkinter import Widget
class MyWidget(Widget): ...
it correctly deduces that MyWidget's base class is Tkinter.Widget. (And in a future version it will probably allow you to click through to that class, show you its methods, etc.)
Custom importers break this feature, and thus make the code harder to analyze for the reader.
That's why I tried argue for making it a standard: all tools will then know about the syntax used and take appropriate action.
(Not all custom importers are bad; there are plenty of reasons to augment the standard importer. But, while custom importers make different interpretations of the namespace possible, I frown upon that particular use.)
(b) is (if at all) a problem only to be taken into account by the author of package X. He may or may not use rel. imports. A 12-year old probably won't (but then: you never know ;).
Which severely limits your ability to do what you want with packages you didn't write.
I know that this sounds politically incorrect in a radical free software world, but often in the end I find it more convenient to conform to the rest of the world and "fit in" than to be different in every little way. Note that my hair isn't blue :-); I've also replaced my "signature" glasses with a more conventional model.
Naa, I don't want to be different just to be plain silly different. The case here is one of maintenance. I have around 12 Python packages which I maintain, some of them public, others proprietary. Due to the large number I try to make them all as easy to handle as possible. Now I can't just go and rename the imports in case I want to put them under some other common package name for application A and then do the same with another package name for application B. I would have to do the same thing for every new release of the packages since there are also others who use the standard mx-based name. I just want the packages to work whereever I put them, e.g. I could link them into the new location using symlinks and be done with the work. Of course there are other ways to make this work (and I want to thank everybody who contributed to the sys.path ideas), but they just add omplexity to a whole different area.
BTW, what is this CP4E thing you're talking about. If it's an syntax aware editor, I have a friend who is really interested in these things... could you send me an URL that I can send him ?
Where have you been? It's on the python.org homepage, has been discussed in c.l.py, c.l.tcl, even c.l.ada, in lwn, and on /.! The syntax aware editor (a proposed super-version of IDLE) is only a small part of it. See python.org/doc/essays/cp4e.html
Nope, haven't heard anything about it -- perhaps I was on vacation. Sound interesting though. An editor where you can just type away (and the editor fills in the gaps) would be great fun.
Oh well... I guess they'll have to use 'mex' if they decide to go the reverse domain way ;-)
Or, in a worse-case scenario, the first Mexican developers using the reverse domain will probably not be aware of the mx toplevel package, and by the time their software hits the street it will be too late.
Well, I guess then they'll have a good reason to upgrade their software. Just like all those companies who made extra money by sticking a "Y2000 + Euro-capable" button on their software. No, seriously, with the proposed extension (see below) this shouldn't be much of a problem because my packages all use capital first letters. The reverse domain name would use lower case ones, e.g. mx.pythonware.pilios or mx.zopistas...
True, perhaps we should lighten this requirement a little when we recode the import mechanism in Python ? E.g. if a local import fails continue the search with the fully qualified name and only if that fails, restart using the local name. This would need some kind of fastpath cache to make the search reasonably fast though.
Now this is something that I would consider.
Should be easy to add to the imputil based core emulation.
Wouldn't it suffice to just put them into one package, e.g. 'python.' ?
And somehow make all user code live implicitly inside that package? I don't see how that solves anything.
No, to free the top-level namespace and make the origin of the imports clearer, e.g. import python.image import PIL.image import zope.image etc.
And believe me, at some point *someone* is going to need to rip out your custom importer because it interferes with *his* custom importer, and he'll choose to replace all your __ imports with absolute package names, rather than trying to add the __ feature to his importer.
Note that with imputil doing its thing, he won't have to worry about adding code to his importer. It'll just pass on the import to my importer. That's the fun part about imputil. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 105 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/