[Python-Dev] Re: Relative import

[Guido van Rossum]

> > 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.

I agree that the use case is not very strong.  There really seem to be
two camps here; some people like scan-up semantics so much they want
to make it the default, others hate it and want to banish even the
bastardized version of it that is the current default ("ambiguous
import" or perhaps we can call it "search current then global").

> > 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.

I like its preciseness, but I have to admit that the three dots are
enticing.

> 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?

from ... import os.path

could be made to work (even though today, in a from-import statement,
the name after the import keyword cannot have dots in it).

> > 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.

But that would case pretty obvious error message, wouldn't it?

> - 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 ;-)

You know, I'm torn on this one.  Maybe some more people can "vote" on
their preferences.

> > 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.

Right. :-)

> 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.

Of course.

--Guido van Rossum (home page: http://www.python.org/~guido/)