relative import broken?

[Alan Isaac]

Are relative imports broken in 2.5?
Directory ``temp`` contains::

__init__.py
test1.py
test2.py

File contents:
__init__.py and test2.py are empty
test1.py contains a single line::

from . import test2

Python 2.5.1 under Win2000, cmd line execution,
produces as output::

Traceback (most recent call last):
File "F:\temp\test1.py", line 1, in <module>
from . import test2
ValueError: Attempted relative import in non-package

Why?

Thanks,
Alan Isaac

 

[Alex Martelli]

Are relative imports broken in 2.5?
Directory ``temp`` contains::

__init__.py
test1.py
test2.py

File contents:
__init__.py and test2.py are empty
test1.py contains a single line::

from . import test2

Python 2.5.1 under Win2000, cmd line execution,
produces as output::

Traceback (most recent call last):
File "F:\temp\test1.py", line 1, in <module>
from . import test2
ValueError: Attempted relative import in non-package

Why?

If you're running test1.py as your main module, then it's not part of a
package, so the relative import should indeed fail as you mention.
OTOH, something like:

$ python -c'from temp import test1'

from the parent directory of temp should work fine. Since you don't
give us the exact command line you're trying to execute, it's impossible
to guess exactly what you're doing.


Alex

 

[Alan Isaac]

If you're running test1.py as your main module, then it's not part of a
package, so the relative import should indeed fail as you mention.

So if I understand you,
in a package, any module that I wish
to make available for execution as a script
(in the usual way, with a main function)
cannot have any relative imports.
Is this right? What is the reason for
this restriction? (And where is it
documented?)

Thank you,
Alan Isaac

 

[Alex Martelli]

So if I understand you,
in a package, any module that I wish
to make available for execution as a script
(in the usual way, with a main function)
cannot have any relative imports.
Is this right? What is the reason for
this restriction? (And where is it
documented?)

The most up-to-date documentation for import and from statements is at
<http://docs.python.org/dev/ref/import.html> but it's still somewhat
incomplete -- it gives the grammar for relative imports, but does not
explain its semantics, nor, for that matter, any of the semantics of
pakages. The discussions about relative imports in particular are
recorded as PEP 328, while an old essay about the semantics of packages
is recorded at a link give on the docs page I mentioned.

Very simply, PEP 328 explains:
"""
Relative Imports and __name__

Relative imports use a module's __name__ attribute to determine that
module's position in the package hierarchy. If the module's name does
not contain any package information (e.g. it is set to '__main__') then
relative imports are resolved as if the module were a top level module,
regardless of where the module is actually located on the file system.
"""
and points to four discussion threads on python-dev which, after much
give and take, led to Guido picking these semantics.

To me, it makes sense: if a module is top-level, and thus not part of a
package (and __main__ in particular is always in that state), then
saying "import from the current package" has no well defined meaning,
because there IS no "current package". Using __name__ rather than
__file__, in turn, makes a lot of sense, because a package's _logical_
structure is defined by its __path__, and need not coincide with any
_physical_ arrangement of directories.

If you have a better and sharper idea about how relative imports should
work in toplevel modules (those whose __name__ indicates they have NOT
been imported as part of a package, including __main__), feel free to
make a case for it on python-dev (python-list is fine for preliminary
discussions and brainstorming, but nothing will happen about any idea
until and unless it's taken to python-dev, survives the scathing barrage
of objections that strongly characterizes that mailing list, and finally
manages to convince Guido.


Alex

 

[Alan Isaac]

To me, it makes sense: if a module is top-level, and thus not part of a
package (and __main__ in particular is always in that state), then
saying "import from the current package" has no well defined meaning,
because there IS no "current package".

Thanks for the explanations.
I do not have an opinion because I have not really thought this through.

One of the things I was hoping for, however, was for a less hackish way
for scripts bundled with a package to access the package modules.

That is, suppose I have directory ``mypackage`` with subdirectory
``scripts``.
What is the pretty way for the scripts to access ``mypackage`` without
assuming ``mypackage`` is in ``sys.path``?

Thanks,
Alan Isaac

 

[Alex Martelli]

Thanks for the explanations.
I do not have an opinion because I have not really thought this through.

One of the things I was hoping for, however, was for a less hackish way
for scripts bundled with a package to access the package modules.

That is, suppose I have directory ``mypackage`` with subdirectory
``scripts``.
What is the pretty way for the scripts to access ``mypackage`` without
assuming ``mypackage`` is in ``sys.path``?

I don't know of any "pretty" way -- I'd do it by path manipulation
(finding mypackage from os.path.abspath(__file__) and inserting its
_parent_ directory in sys.path).


Alex

 

[Alan Isaac]

I don't know of any "pretty" way -- I'd do it by path manipulation
(finding mypackage from os.path.abspath(__file__) and inserting its
_parent_ directory in sys.path).

Yes, that seems to be the standard solution.
I find it ugly. Anyway, I suppose my question remains:
why are we constrained from solving this with
a relative import? (And I suppose your answer will be:
well then, relative to *what*? I am having trouble
seeing why that answer cannot be given a clear riposte.)

Thanks,
Alan

 

[Alan Isaac]

Yes, that seems to be the standard solution.
I find it ugly.

Just to confirm that I am right to find it ugly:
does this not clearly introduce the possibility of name clashes?
Or am I overlooking some trick?

Alan Isaac

 

[Alex Martelli]

Yes, that seems to be the standard solution.
I find it ugly. Anyway, I suppose my question remains:
why are we constrained from solving this with
a relative import? (And I suppose your answer will be:
well then, relative to *what*? I am having trouble
seeing why that answer cannot be given a clear riposte.)

So what do you think the answer should be?

Alex

 

[Alex Martelli]

Just to confirm that I am right to find it ugly:
does this not clearly introduce the possibility of name clashes?
Or am I overlooking some trick?

If you use sys.path.insert(0, ...), not sys.path.append, I'm not sure
what "name clashes" you're thinking of -- as long as you avoid naming
your modules the same as ones in the standard library (which is a good
practice I heartily recommend), of course, what scenario do you fear?

You can have more control about _where_ stuff can get imported from by
directly calling the __import__ builtin, but that's not often needed.


Alex

 

[Alan Isaac]

So what do you think the answer should be?

Well I'm clearly not seeing into the depths of this,
so I'm not going to propose anything. But to stick
close to my example, I am not clear why a script
when executed could not do imports relative to
__file__. This seems like natural behavior to me.

Thanks,
Alan Isaac

 

[Alan Isaac]

Very simply, PEP 328 explains:
"""
Relative Imports and __name__

Relative imports use a module's __name__ attribute to determine that
module's position in the package hierarchy. If the module's name does
not contain any package information (e.g. it is set to '__main__') then
relative imports are resolved as if the module were a top level module,
regardless of where the module is actually located on the file system.
"""

To change my question somewhat, can you give me an example
where this behavior (when __name__ is '__main__') would
be useful for a script? (I.e., more useful than importing relative
to the directory holding the script, as indicated by __file__.)

Thanks,
Alan Isaac

 

[Leo Kislov]

To change my question somewhat, can you give me an example
where this behavior (when __name__ is '__main__') would
be useful for a script? (I.e., more useful than importing relative
to the directory holding the script, as indicated by __file__.)

Do you realize it's a different behaviour and it won't work for some
packages? One possible alternative is to assume empty parent
package and let from . import foo work but not
from .. import bar or any other upper levels. The package author
should also realize __init__.py will be ignored.

-- Leo