[Python-ideas] Import and '..', '../..' in serach path.

Brett Cannon brett at python.org
Wed Jan 31 20:48:53 CET 2007

On 1/30/07, Ron Adam <rrr at ronadam.com> wrote:
> Brett Cannon wrote:
> > I just don't see this as a common enough problem to warrant
> > documenting it somewhere (and I have no clue where that "somewhere"
> > would be).
> I expected that someone would say that.
> How about adding a note at the bottom of PEP 328. That was one of the places I
> looked for a way to resolve this.  Or possibly posting a message on
> python-ideas.  Consider it done  ;-)
> A note on PEP 328 might be a good idea still.  I have no idea what the best
> wording would be.  The import tutorial is another place where a note clarifying
> relative imports can't be used for stand alone scripts is needed.

Sure, but that is not my PEP.  That is something to bug Thomas Wouters about.

> The nice thing about adjusting sys.path directly is you can then move back and
> forth from different same named versions in development without doing renames.
> If you do a rename, you also have to remember to rename all the submodule
> absolute references in the package as well.  Another alternative is to hide the
> ones you don't want by renaming them.  Then you have to do renames to switch
> back to them.  That makes it more difficult to do side by side comparisons as well.

Right but the point of relative imports is to help prevent renaming.
It's a catch-22 situation of what matters more to you.

> Altering PYTHONPATH is another way to do it, but you also need to switch it back
> if you switch versions.  But if you forget to edit it back, and use a version
> not on the path, it will import modules from the version on the path.
> In this case the package I'm working on may replace pydoc.py module in pythons
> library. (no promises though) The name matters so that site.py can locate the
> help function.  It's convenient for me to be able to easily and dependably
> compare different working versions.
> A few things to consider...
> -----
> According to PEP 328:
> You may use relative imports freely. In Python 2.6, any import statement that
> results in an intra-package import will raise DeprecationWarning (this also
> applies to from <> import that fails to use the relative import syntax). In
> Python 2.7, import will always be an absolute import (and the __future__
> directive will no longer be needed).
> -----
> So It will probably come up more often as more people start using absolute
> imports and the '.' style relative imports. Or as you put it, more people get
> "bitten".


> Take a look at how much __name__ == '__main__' is used in the standard library.
>   Those modules won't be able to use relative imports.  They will need to be
> updated and can use only absolute imports.

It's possible.  Maybe this will finally push forward the idea of
having a proper 'main' function or something.

> Some people will probably want a way to have relative imports work with modules
> meant to be run as scripts (in packages).
> An optional function (or property) may be a good way to resolve both of these
> package self reference situations without any changes to the default behavior.

Yeah, some built-in or something might do it that lets you decorate
what function is to be the 'main' function and maybe do some magic to
make it resolve properly.


More information about the Python-ideas mailing list