from __future__ import absolute_import ?

Discussion in 'Python' started by Ron Adam, Feb 2, 2007.

  1. Ron Adam

    Ron Adam Guest

    from __future__ import absolute_import

    Is there a way to check if this is working? I get the same results with or
    without it.

    Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
    [MSC v.1310 32 bit (Intel)] on win 32


    _Ron
     
    Ron Adam, Feb 2, 2007
    #1
    1. Advertising

  2. Ron Adam

    Peter Otten Guest

    Ron Adam wrote:

    >
    > from __future__ import absolute_import
    >
    > Is there a way to check if this is working? I get the same results with
    > or without it.
    >
    > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
    > [MSC v.1310 32 bit (Intel)] on win 32


    If there are two modules 'foo', one at the toplevel and the other inside a
    package 'bar',

    from __future__ import absolute_import
    import foo

    will import the toplevel module whereas

    import foo

    will import bar.foo. A messy demonstration:

    $ ls bar
    absolute.py foo.py __init__.py relative.py
    $ cat bar/absolute.py
    from __future__ import absolute_import
    import foo
    $ cat bar/relative.py
    import foo
    $ cat foo.py
    print "toplevel"
    $ cat bar/foo.py
    print "in bar"
    $ python2.5 -c 'import bar.absolute'
    toplevel
    $ python2.5 -c 'import bar.relative'
    in bar


    Another example is here:

    http://mail.python.org/pipermail/python-list/2007-January/422889.html

    Peter
     
    Peter Otten, Feb 2, 2007
    #2
    1. Advertising

  3. Ron Adam

    Peter Otten Guest

    Peter Otten wrote:

    > If there are two modules 'foo', one at the toplevel and the other inside a
    > package 'bar',
    >
    > from __future__ import absolute_import
    > import foo
    >
    > will import the toplevel module whereas
    >
    > import foo
    >
    > will import bar.foo.


    .... provided these imports are performed from modules within 'bar'.

    Peter
     
    Peter Otten, Feb 2, 2007
    #3
  4. Ron Adam

    Ron Adam Guest

    Peter Otten wrote:
    > Ron Adam wrote:
    >
    >> from __future__ import absolute_import
    >>
    >> Is there a way to check if this is working? I get the same results with
    >> or without it.
    >>
    >> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
    >> [MSC v.1310 32 bit (Intel)] on win 32

    >
    > If there are two modules 'foo', one at the toplevel and the other inside a
    > package 'bar',
    >
    > from __future__ import absolute_import
    > import foo
    >
    > will import the toplevel module whereas
    >
    > import foo
    >
    > will import bar.foo. A messy demonstration:
    >
    > $ ls bar
    > absolute.py foo.py __init__.py relative.py
    > $ cat bar/absolute.py
    > from __future__ import absolute_import
    > import foo
    > $ cat bar/relative.py
    > import foo
    > $ cat foo.py
    > print "toplevel"
    > $ cat bar/foo.py
    > print "in bar"
    > $ python2.5 -c 'import bar.absolute'
    > toplevel
    > $ python2.5 -c 'import bar.relative'
    > in bar
    >
    >
    > Another example is here:
    >
    > http://mail.python.org/pipermail/python-list/2007-January/422889.html
    >
    > Peter


    Thanks, that helped, I see why I was having trouble.


    work
    |
    |- foo.py # print "foo not in bar"
    |
    `- bar
    |
    |- __init__.py
    |
    |- foo.py # print "foo in bar"
    |
    |- absolute.py # from __futer__ import absolute_import
    | # import foo
    |
    `- relative.py # import foo


    * Where "work" is in the path.


    (1)

    C:\work>python -c "import bar.absolute"
    foo not in bar

    C:\work>python -c "import bar.relative"
    foo in bar


    (2)

    C:\work>python -m "bar.absolute"
    foo not in bar

    C:\work>python -m "bar.relative"
    foo not in bar


    (3)

    C:\work>python
    Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win
    32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import bar.absolute

    foo not in bar
    >>> import bar.relative

    foo in bar


    (4)

    C:\work>cd bar

    C:\work\bar>python -c "import bar.absolute"
    foo in bar

    C:\work\bar>python -c "import bar.relative"
    foo in bar


    (5)

    C:\work\bar>python
    Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win
    32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import bar.absolute

    foo in bar
    >>> import bar.relative

    foo in bar
    >>>




    Case (2) seems like it is a bug.


    Why not also have (4), and (5) do the same as cases (1) and (3)?


    in cases (4) and (5), that is the result I would expect if I did:

    import absolute # with no 'bar.' prefix.
    import relative


    From what I understand, in 2.6 relative imports will be depreciated, and in 2.7
    they will raise an error. (providing plans don't change)

    Would that mean the absolute imports in (4) and (5) would either find the 'foo
    not in bar' or raise an error?



    If so, is there any way to force (warning/error) behavior now?

    Cheers,
    Ron
     
    Ron Adam, Feb 2, 2007
    #4
  5. Ron Adam

    Peter Otten Guest

    Ron Adam wrote:

    > Peter Otten wrote:
    >> Ron Adam wrote:
    >>
    >>> from __future__ import absolute_import
    >>>
    >>> Is there a way to check if this is working? I get the same results with
    >>> or without it.
    >>>
    >>> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
    >>> [MSC v.1310 32 bit (Intel)] on win 32

    >>
    >> If there are two modules 'foo', one at the toplevel and the other inside
    >> a package 'bar',
    >>
    >> from __future__ import absolute_import
    >> import foo
    >>
    >> will import the toplevel module whereas
    >>
    >> import foo
    >>
    >> will import bar.foo. A messy demonstration:
    >>
    >> $ ls bar
    >> absolute.py foo.py __init__.py relative.py
    >> $ cat bar/absolute.py
    >> from __future__ import absolute_import
    >> import foo
    >> $ cat bar/relative.py
    >> import foo
    >> $ cat foo.py
    >> print "toplevel"
    >> $ cat bar/foo.py
    >> print "in bar"
    >> $ python2.5 -c 'import bar.absolute'
    >> toplevel
    >> $ python2.5 -c 'import bar.relative'
    >> in bar
    >>
    >>
    >> Another example is here:
    >>
    >> http://mail.python.org/pipermail/python-list/2007-January/422889.html
    >>
    >> Peter

    >
    > Thanks, that helped, I see why I was having trouble.
    >
    >
    > work
    > |
    > |- foo.py # print "foo not in bar"
    > |
    > `- bar
    > |
    > |- __init__.py
    > |
    > |- foo.py # print "foo in bar"
    > |
    > |- absolute.py # from __futer__ import absolute_import
    > | # import foo
    > |
    > `- relative.py # import foo
    >
    >
    > * Where "work" is in the path.
    >
    >
    > (1)
    >
    > C:\work>python -c "import bar.absolute"
    > foo not in bar
    >
    > C:\work>python -c "import bar.relative"
    > foo in bar
    >
    >
    > (2)
    >
    > C:\work>python -m "bar.absolute"
    > foo not in bar
    >
    > C:\work>python -m "bar.relative"
    > foo not in bar
    >
    >
    > (3)
    >
    > C:\work>python
    > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
    > on win 32
    > Type "help", "copyright", "credits" or "license" for more information.
    > >>> import bar.absolute

    > foo not in bar
    > >>> import bar.relative

    > foo in bar
    >
    >
    > (4)
    >
    > C:\work>cd bar


    A path below the package level is generally a good means to shoot yourself
    in the foot and should be avoided with or without absolute import.

    > C:\work\bar>python -c "import bar.absolute"
    > foo in bar
    >
    > C:\work\bar>python -c "import bar.relative"
    > foo in bar
    >
    >
    > (5)
    >
    > C:\work\bar>python
    > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
    > on win 32
    > Type "help", "copyright", "credits" or "license" for more information.
    > >>> import bar.absolute

    > foo in bar
    > >>> import bar.relative

    > foo in bar
    > >>>

    >
    >
    >
    > Case (2) seems like it is a bug.


    I think so, too.

    > Why not also have (4), and (5) do the same as cases (1) and (3)?


    The work/bar directory is the current working directory and occurs in the
    path before the work directory. When bar.absolute imports foo python is
    unaware that work/bar/foo.py is part of the bar package.

    > in cases (4) and (5), that is the result I would expect if I did:
    >
    > import absolute # with no 'bar.' prefix.
    > import relative
    >
    >
    > From what I understand, in 2.6 relative imports will be depreciated, and
    > in 2.7
    > they will raise an error. (providing plans don't change)
    >
    > Would that mean the absolute imports in (4) and (5) would either find the
    > 'foo not in bar' or raise an error?


    No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is only
    for the relative import which would have to be spelt

    from . import foo

    in an absolute-import-as-default environment;

    import foo

    would always be an absolute import.

    > If so, is there any way to force (warning/error) behavior now?


    I don't know.

    Peter
     
    Peter Otten, Feb 3, 2007
    #5
  6. Ron Adam

    Ron Adam Guest

    Peter Otten wrote:
    > Ron Adam wrote:
    >
    >>
    >> work
    >> |
    >> |- foo.py # print "foo not in bar"
    >> |
    >> `- bar
    >> |
    >> |- __init__.py
    >> |
    >> |- foo.py # print "foo in bar"
    >> |
    >> |- absolute.py # from __futer__ import absolute_import
    >> | # import foo
    >> |
    >> `- relative.py # import foo
    >>
    >>
    >> * Where "work" is in the path.
    >>
    >>
    >> (1)
    >>
    >> C:\work>python -c "import bar.absolute"
    >> foo not in bar
    >>
    >> C:\work>python -c "import bar.relative"
    >> foo in bar
    >>
    >>
    >> (2)
    >>
    >> C:\work>python -m "bar.absolute"
    >> foo not in bar
    >>
    >> C:\work>python -m "bar.relative"
    >> foo not in bar
    >>
    >>
    >> (3)
    >>
    >> C:\work>python
    >> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
    >> on win 32
    >> Type "help", "copyright", "credits" or "license" for more information.
    >> >>> import bar.absolute

    >> foo not in bar
    >> >>> import bar.relative

    >> foo in bar
    >>
    >>
    >> (4)
    >>
    >> C:\work>cd bar

    >
    > A path below the package level is generally a good means to shoot yourself
    > in the foot and should be avoided with or without absolute import.


    Seems so. :-/


    >> C:\work\bar>python -c "import bar.absolute"
    >> foo in bar
    >>
    >> C:\work\bar>python -c "import bar.relative"
    >> foo in bar
    >>
    >>
    >> (5)
    >>
    >> C:\work\bar>python
    >> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
    >> on win 32
    >> Type "help", "copyright", "credits" or "license" for more information.
    >> >>> import bar.absolute

    >> foo in bar
    >> >>> import bar.relative

    >> foo in bar
    >> >>>

    >>
    >>
    >>
    >> Case (2) seems like it is a bug.

    >
    > I think so, too.


    This one is the reasons I had trouble figuring it out. I was using the -m
    command option when I tried to test it.

    There is a bug report on absolute/relative imports already. I'm not sure if
    this particular item is covered under it or not. Doesn't sound like it as the
    bug report address the relative aspects of it.


    >> Why not also have (4), and (5) do the same as cases (1) and (3)?

    >
    > The work/bar directory is the current working directory and occurs in the
    > path before the work directory.


    Yes. Unfortunately this is a side effect of using the os's directory structure
    to represent a python "package" structure. If a package was represented as a
    combined single file. Then the working directory would always be the package
    directory.


    > When bar.absolute imports foo python is
    > unaware that work/bar/foo.py is part of the bar package.


    Umm.... isn't the "bar" stuck on the front of "bar.absolute" a pretty obvious
    hint. ;-)

    If you run the module directly as a file...

    python bar/foo.py
    or python foo.py

    Then I can see that it doesn't know. But even then, it's possible to find out.
    ie... just check for an __init__.py file.

    Python has a certain minimalist quality where it tries to do a lot with a
    minimum amount of resources, which I generally love. But in this situation that
    might not be the best thing. It would not be difficult for python to detect if
    a module is in a package, and determine the package location. With the move to
    explicit absolute/relative imports, it would make since if python also were a
    little smarter in this area.


    >> in cases (4) and (5), that is the result I would expect if I did:
    >>
    >> import absolute # with no 'bar.' prefix.
    >> import relative
    >>
    >>
    >> From what I understand, in 2.6 relative imports will be depreciated, and
    >> in 2.7
    >> they will raise an error. (providing plans don't change)
    >>
    >> Would that mean the absolute imports in (4) and (5) would either find the
    >> 'foo not in bar' or raise an error?

    >
    > No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is only
    > for the relative import which would have to be spelt
    >
    > from . import foo


    Was that a 'yes' for exampels 4 and 5, since 1,2 and 3 are 'no'?


    > in an absolute-import-as-default environment;
    >
    > import foo
    >
    > would always be an absolute import.


    But what is the precise meaning of "absolute import" in this un-dotted case?

    Currently it is:

    "A module or package that is located in sys.path or the current directory".

    But maybe a narrower interpretation may be better?:

    "A module or package found in sys.path, or the current directory
    and is *not* in a package."

    If it's in a package then the dotted "absolute" name should be used. Right?


    I guess what I'm getting at, is it would be nice if the following were always true.

    from __import__ import absolute_import


    import thispackage.module
    import thispackage.subpackage

    # If thispackage is the same name as the current package,
    # then do not look on sys.path.


    import otherpackage.module
    import otherpackage.subpackage

    # If otherpackage is a different name from the current package,
    # then do not look in this package.


    import module
    import package

    # Module and package are not in a package, even the current one,
    # so don't look in any packages, even if the current directory is
    # in this (or other) package.


    If these were always true, :) I think it avoid some situations where things
    don't work, or don't work like one would expect.

    In addition to the above, when executing modules directly from a directory
    inside a package, if python were to detect the package and then follow these
    same rules. It would avoid even more surprises. While you are editing modules
    in a package, you could then run them directly and get the same behavior you get
    if you cd'd out of the package and then ran it.

    All in all, what I'm suggesting is that the concept of a package (type) be much
    stronger than that of a search path or current directory. And that this would
    add a fair amount of reliability to the language.

    IMHO, of course. :)

    Cheers,
    Ron



    >> If so, is there any way to force (warning/error) behavior now?

    >
    > I don't know.
    >
    > Peter
    >
     
    Ron Adam, Feb 3, 2007
    #6
  7. Ron Adam

    Peter Otten Guest

    Ron Adam wrote:

    > Peter Otten wrote:
    >> Ron Adam wrote:
    >>
    >>>
    >>> work
    >>> |
    >>> |- foo.py # print "foo not in bar"
    >>> |
    >>> `- bar
    >>> |
    >>> |- __init__.py
    >>> |
    >>> |- foo.py # print "foo in bar"
    >>> |
    >>> |- absolute.py # from __futer__ import absolute_import
    >>> | # import foo
    >>> |
    >>> `- relative.py # import foo
    >>>
    >>>
    >>> * Where "work" is in the path.
    >>>
    >>>
    >>> (1)
    >>>
    >>> C:\work>python -c "import bar.absolute"
    >>> foo not in bar
    >>>
    >>> C:\work>python -c "import bar.relative"
    >>> foo in bar
    >>>
    >>>
    >>> (2)
    >>>
    >>> C:\work>python -m "bar.absolute"
    >>> foo not in bar
    >>>
    >>> C:\work>python -m "bar.relative"
    >>> foo not in bar
    >>>
    >>>
    >>> (3)
    >>>
    >>> C:\work>python
    >>> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
    >>> (Intel)] on win 32
    >>> Type "help", "copyright", "credits" or "license" for more information.
    >>> >>> import bar.absolute
    >>> foo not in bar
    >>> >>> import bar.relative
    >>> foo in bar
    >>>
    >>>
    >>> (4)
    >>>
    >>> C:\work>cd bar

    >>
    >> A path below the package level is generally a good means to shoot
    >> yourself in the foot and should be avoided with or without absolute
    >> import.

    >
    > Seems so. :-/
    >
    >
    >>> C:\work\bar>python -c "import bar.absolute"
    >>> foo in bar
    >>>
    >>> C:\work\bar>python -c "import bar.relative"
    >>> foo in bar
    >>>
    >>>
    >>> (5)
    >>>
    >>> C:\work\bar>python
    >>> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
    >>> (Intel)] on win 32
    >>> Type "help", "copyright", "credits" or "license" for more information.
    >>> >>> import bar.absolute
    >>> foo in bar
    >>> >>> import bar.relative
    >>> foo in bar
    >>> >>>
    >>>
    >>>
    >>>
    >>> Case (2) seems like it is a bug.

    >>
    >> I think so, too.

    >
    > This one is the reasons I had trouble figuring it out. I was using the -m
    > command option when I tried to test it.
    >
    > There is a bug report on absolute/relative imports already. I'm not sure
    > if
    > this particular item is covered under it or not. Doesn't sound like it as
    > the bug report address the relative aspects of it.
    >
    >
    >>> Why not also have (4), and (5) do the same as cases (1) and (3)?

    >>
    >> The work/bar directory is the current working directory and occurs in the
    >> path before the work directory.

    >
    > Yes. Unfortunately this is a side effect of using the os's directory
    > structure
    > to represent a python "package" structure. If a package was represented
    > as a
    > combined single file. Then the working directory would always be the
    > package directory.
    >
    >
    > > When bar.absolute imports foo python is
    > > unaware that work/bar/foo.py is part of the bar package.

    >
    > Umm.... isn't the "bar" stuck on the front of "bar.absolute" a pretty
    > obvious
    > hint. ;-)
    >
    > If you run the module directly as a file...
    >
    > python bar/foo.py
    > or python foo.py
    >
    > Then I can see that it doesn't know. But even then, it's possible to find
    > out.
    > ie... just check for an __init__.py file.
    >
    > Python has a certain minimalist quality where it tries to do a lot with a
    > minimum amount of resources, which I generally love. But in this
    > situation that
    > might not be the best thing. It would not be difficult for python to
    > detect if
    > a module is in a package, and determine the package location. With the
    > move to explicit absolute/relative imports, it would make since if python
    > also were a little smarter in this area.


    I have not used the new import behaviour seriously, but -- I think I like
    it :)

    >>> in cases (4) and (5), that is the result I would expect if I did:
    >>>
    >>> import absolute # with no 'bar.' prefix.
    >>> import relative
    >>>
    >>>
    >>> From what I understand, in 2.6 relative imports will be depreciated,
    >>> and in 2.7
    >>> they will raise an error. (providing plans don't change)
    >>>
    >>> Would that mean the absolute imports in (4) and (5) would either find
    >>> the 'foo not in bar' or raise an error?

    >>
    >> No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is
    >> only for the relative import which would have to be spelt
    >>
    >> from . import foo

    >
    > Was that a 'yes' for exampels 4 and 5, since 1,2 and 3 are 'no'?


    (4) and (5) are misconfigurations, IMHO.

    >> in an absolute-import-as-default environment;
    >>
    >> import foo
    >>
    >> would always be an absolute import.

    >
    > But what is the precise meaning of "absolute import" in this un-dotted
    > case?
    >
    > Currently it is:
    >
    > "A module or package that is located in sys.path or the current
    > directory".
    >
    > But maybe a narrower interpretation may be better?:
    >
    > "A module or package found in sys.path, or the current directory
    > and is *not* in a package."


    You'd have to add a not-in-package test to every import - I don't think it's
    worth the effort.

    > If it's in a package then the dotted "absolute" name should be used.
    > Right?


    Either that or the full path. The dotted path makes it easy to move the
    module between packages.

    > I guess what I'm getting at, is it would be nice if the following were
    > always true.
    >
    > from __import__ import absolute_import
    >
    >
    > import thispackage.module
    > import thispackage.subpackage
    >
    > # If thispackage is the same name as the current package,
    > # then do not look on sys.path.
    >
    >
    > import otherpackage.module
    > import otherpackage.subpackage
    >
    > # If otherpackage is a different name from the current package,
    > # then do not look in this package.
    >
    >
    > import module
    > import package
    >
    > # Module and package are not in a package, even the current one,
    > # so don't look in any packages, even if the current directory is
    > # in this (or other) package.
    >
    >
    > If these were always true, :) I think it avoid some situations where
    > things don't work, or don't work like one would expect.
    >
    > In addition to the above, when executing modules directly from a directory
    > inside a package, if python were to detect the package and then follow
    > these
    > same rules. It would avoid even more surprises. While you are editing
    > modules in a package, you could then run them directly and get the same
    > behavior you get if you cd'd out of the package and then ran it.
    >
    > All in all, what I'm suggesting is that the concept of a package (type) be
    > much
    > stronger than that of a search path or current directory. And that this
    > would add a fair amount of reliability to the language.


    I think if you go that way, ultimately you will need some kind of package
    registry. I expect that the new import behaviour will get you 99 percent
    there with one percent of the hassle. But we will see...

    Peter
     
    Peter Otten, Feb 9, 2007
    #7
  8. Ron Adam

    Ron Adam Guest

    Peter Otten wrote:
    > Ron Adam wrote:
    >
    >> Peter Otten wrote:
    >>> Ron Adam wrote:
    >>>
    >>>> work
    >>>> |
    >>>> |- foo.py # print "foo not in bar"
    >>>> |
    >>>> `- bar
    >>>> |
    >>>> |- __init__.py
    >>>> |
    >>>> |- foo.py # print "foo in bar"
    >>>> |
    >>>> |- absolute.py # from __futer__ import absolute_import
    >>>> | # import foo
    >>>> |
    >>>> `- relative.py # import foo



    >>>> (4)


    >>>> C:\work\bar>python -c "import bar.absolute"
    >>>> foo in bar



    >>>> (5)


    >>>> >>> import bar.absolute
    >>>> foo in bar



    > (4) and (5) are misconfigurations, IMHO.


    But it's a very common configuration. So it will most likely cause problems for
    someone.

    From what I understand these will probably do what I want in python 2.6, which
    is either import the foo not in bar, or give an error if foo not in bar doesn't
    exist instead of importing foo in bar.


    >>> in an absolute-import-as-default environment;
    >>>
    >>> import foo
    >>>
    >>> would always be an absolute import.

    >> But what is the precise meaning of "absolute import" in this un-dotted
    >> case?
    >>
    >> Currently it is:
    >>
    >> "A module or package that is located in sys.path or the current
    >> directory".
    >>
    >> But maybe a narrower interpretation may be better?:
    >>
    >> "A module or package found in sys.path, or the current directory
    >> and is *not* in a package."

    >
    > You'd have to add a not-in-package test to every import - I don't think it's
    > worth the effort.


    No, you only need to test the (first) module you explicitly run is in a package.
    For any imports after that, the absolute import code can exclude any of the
    package directories for un-dotted top level absolute imports. It may be a
    performance net gain because there is less disk searching.


    >> All in all, what I'm suggesting is that the concept of a package (type) be
    >> much
    >> stronger than that of a search path or current directory. And that this
    >> would add a fair amount of reliability to the language.

    >
    > I think if you go that way, ultimately you will need some kind of package
    > registry. I expect that the new import behaviour will get you 99 percent
    > there with one percent of the hassle. But we will see...


    It won't need a registry.

    Check the python-ideas list for further discussion on this.

    Cheers,
    Ron
     
    Ron Adam, Feb 9, 2007
    #8
    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. Logan
    Replies:
    3
    Views:
    818
    Michael Hudson
    Nov 25, 2003
  2. Jacek Generowicz

    from __future__ import decorators

    Jacek Generowicz, Jan 13, 2005, in forum: Python
    Replies:
    8
    Views:
    395
    Jacek Generowicz
    Jan 17, 2005
  3. Replies:
    2
    Views:
    323
  4. Nate Finch

    Not understanding absolute_import

    Nate Finch, Apr 5, 2007, in forum: Python
    Replies:
    2
    Views:
    345
    Peter Otten
    Apr 8, 2007
  5. Gabriel Genellina

    Re: from __future__ import absolute_import issue

    Gabriel Genellina, May 22, 2009, in forum: Python
    Replies:
    1
    Views:
    739
    Gabriel Genellina
    May 24, 2009
Loading...

Share This Page