[Python-Dev] Relative Package Imports

[Tim Peters]

[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