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

[Brett Cannon]

On 1/30/07, Ron Adam <rrr at ronadam.com> wrote:
> Brett Cannon wrote:
[SNIP]
> > 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".
>

Probably.

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

-Brett