[MAL]
... 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 complexity to a whole different area.
The complexity is already in that area, and for all of us. It can be dealt with. Adding new complexity elsewhere doesn't decrease the complexity that's already there, it just adds more and new kinds of stuff to worry about. [Guido]
... 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.
As I recall, the old ni took the initial "__" as referring to the *current* package. So where you intend to write import __.sibling.func it was written under ni as import __.__.sibling.func Since ni is semi-blessed prior art, some other joker is going to slam in an Importer to use those rules. I mix your packages with theirs, and then the meaning of "__" depends on whose Importer sees the damn thing first. Again complexity spreads. If Jim is wary of top-level name collisions now, wait until he thinks about naming-gimmick collisions <wink>. Guido is telling the truth: no package is going into Dragon's products unless it's rewritten to purge dicey name tricks. I think we're all in favor of Greg's imputil approach, but where it adds real value (primarily in allowing imports to get satisfied from sources other than direct file images). if-it's-in-a-file-you-just-import-it-by-name-ly y'rs - tim