Re: from __future__ import absolute_import ?

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



.

Relevant Pages

  • Re: Insert with response
    ... FooBar, there's no way and no need to put them in synch. ... column in the foo table to 250 calumns in the bar table. ... set statistics time off ...
    (microsoft.public.sqlserver.programming)
  • Re: Magic function
    ... processing objects created in root at depth 3 ... root obj2 at depth 3 ... processing objects created in foo at depth 2 ... processing objects created in bar at depth 0 ...
    (comp.lang.python)
  • Re: from __future__ import absolute_import ?
    ... package 'bar', ... import foo ... will import the toplevel module whereas ... $ cat bar/absolute.py ...
    (comp.lang.python)
  • Re: from __future__ import absolute_import ?
    ... foo not in bar ... Unfortunately this is a side effect of using the os's directory structure to represent a python "package" structure. ...
    (comp.lang.python)
  • Passing "dash" Options to a procedure
    ... >my_proc cat ... >my_proc -var2 dog ...
    (comp.lang.tcl)