relative import broken?

Discussion in 'Python' started by Alan Isaac, Apr 28, 2007.

  1. Alan Isaac

    Alan Isaac Guest

    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
    Alan Isaac, Apr 28, 2007
    #1
    1. Advertising

  2. Alan Isaac <> wrote:

    > 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
    Alex Martelli, Apr 28, 2007
    #2
    1. Advertising

  3. Alan Isaac

    Alan Isaac Guest

    "Alex Martelli" <> wrote in message
    news:1hxa9x3.c0unyd1jw7vu9N%...
    > 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
    Alan Isaac, Apr 29, 2007
    #3
  4. Alan Isaac <> wrote:

    > "Alex Martelli" <> wrote in message
    > news:1hxa9x3.c0unyd1jw7vu9N%...
    > > 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?)


    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
    Alex Martelli, Apr 30, 2007
    #4
  5. Alan Isaac

    Alan Isaac Guest

    "Alex Martelli" <> wrote in message
    news:1hxcdkq.47p2r6beuctcN%...
    > 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
    Alan Isaac, Apr 30, 2007
    #5
  6. Alan Isaac <> wrote:

    > "Alex Martelli" <> wrote in message
    > news:1hxcdkq.47p2r6beuctcN%...
    > > 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``?


    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
    Alex Martelli, May 1, 2007
    #6
  7. Alan Isaac

    Alan Isaac Guest

    "Alex Martelli" <> wrote in message
    news:1hxeg2v.1ct59rv3oyq87N%...
    > 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, May 1, 2007
    #7
  8. Alan Isaac

    Alan Isaac Guest

    > "Alex Martelli" <> wrote in message
    > news:1hxeg2v.1ct59rv3oyq87N%...
    > > 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).

    >


    "Alan Isaac" <> wrote in message
    news:7nNZh.4420$st3.1414@trnddc06...
    > 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
    Alan Isaac, May 2, 2007
    #8
  9. Alan Isaac <> wrote:

    > "Alex Martelli" <> wrote in message
    > news:1hxeg2v.1ct59rv3oyq87N%...
    > > 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.)


    So what do you think the answer should be?

    Alex
    Alex Martelli, May 2, 2007
    #9
  10. Alan Isaac <> wrote:

    > > "Alex Martelli" <> wrote in message
    > > news:1hxeg2v.1ct59rv3oyq87N%...
    > > > 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).

    > >

    >
    > "Alan Isaac" <> wrote in message
    > news:7nNZh.4420$st3.1414@trnddc06...
    > > 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?


    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
    Alex Martelli, May 2, 2007
    #10
  11. Alan Isaac

    Alan Isaac Guest

    "Alex Martelli" <> wrote in message
    news:1hxgczf.1l5eh5j1vln0z9N%...
    > 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, May 2, 2007
    #11
  12. Alan Isaac

    Alan Isaac Guest

    "Alex Martelli" <> wrote in message
    news:1hxcdkq.47p2r6beuctcN%...
    > 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
    Alan Isaac, May 3, 2007
    #12
  13. Alan Isaac

    Leo Kislov Guest

    On May 3, 10:08 am, "Alan Isaac" <> wrote:
    > "Alex Martelli" <> wrote in message
    >
    > news:1hxcdkq.47p2r6beuctcN%...
    >
    > > 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__.)


    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
    Leo Kislov, May 4, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Symon
    Replies:
    1
    Views:
    1,548
  2. test

    relative import broken?

    test, Apr 30, 2008, in forum: Python
    Replies:
    7
    Views:
    285
  3. Steven D'Aprano

    Why are "broken iterators" broken?

    Steven D'Aprano, Sep 21, 2008, in forum: Python
    Replies:
    8
    Views:
    648
  4. Cameron Simpson

    Re: Why are "broken iterators" broken?

    Cameron Simpson, Sep 22, 2008, in forum: Python
    Replies:
    0
    Views:
    584
    Cameron Simpson
    Sep 22, 2008
  5. Fredrik Lundh

    Re: Why are "broken iterators" broken?

    Fredrik Lundh, Sep 22, 2008, in forum: Python
    Replies:
    0
    Views:
    603
    Fredrik Lundh
    Sep 22, 2008
Loading...

Share This Page