[Python-Dev] Re: Relative import

[Werner Schiendl]

"Guido van Rossum" <guido at python.org> wrote

>
> I think someone actually posted a use case: they were referring to a
> global 3rd party module from within a package, and then later they
> were moving the module into the package.  For both to work without
> changes to the import statement the scan would have to go all the way
> up.
>

Why should this sort of thing work "automatically"?
When I restructure a package's modules, I don't usually assume that all
imports will continue to work unchanged.

The main use case IMHO is to move an entire package (or self contained
module) in a package to achive some sort of required structuring or, more
important, resolve naming conflicts. This includes adding or re-naming some
organizational package names do to company merging or aquisitions.

> If we can disregard this use case, I still like my original proposal
> better, because it is more explicit: you have to use the right
> number of dots, and (like Unix paths starting with ../ or ../../ etc.)
> it is still completely explicit what you are referring to (assuming
> the current package/directory is known).
>

+1

I like your original proposal more than this one.

There should be some solution about from-less import however, to support the
fully-qualified name syntax. For example, I prefer writing "struct.pack"
over writing just "pack" because it is more explicit to the reader what
happens. Or e. g. os.path.split is another example.

Maybe just omit the dots for the name?

> But I expect the ... version will work just as well in practice: in
> debugged code, the ... refers to a particular ancestor, so
> what's above that is irrelevant; and what's below that is typically
> only two or at most three levels deep -- I should think a group of
> cooperating package authors who can't keep a namespace of that size
> coordinated will have bigger problems...

I'd prefer to explicitly specify the number of steps "up" the hierarchy.

- It prevents accidentially taking a wrong module (e. g. a "global" one)
because a module is missing.

- It prevents changing semantics because someone (else) adds a module with
that name on some other level of the hierarchy.

- Explicit is better than implicit ;-)

>
> And the advantage of the ... version is that it's more conspicuous
> than a single dot (for the most common case), and you don't have to
> count dots.
>

If there are more than 2 (or maybe 3) dots in the original proposal's use, I
think something is wrong
with package structure - not with the syntax.

And you are normally importing modules from your own package with relative
imports, so there should hardly be a need to "count the dots" I think.

/ Werner