Re: from __future__ import absolute_import ?

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

.

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: table of contents problem with longtable and bibliography
    ... %%start of template ... foo & bar ... class file or some package file available. ... foo & bar \\ ...
    (comp.text.tex)
  • Re: Loading Packages
    ... If you don't want to get both foo and bar when [package require]ing ... you can use the [load] command selectively. ...
    (comp.lang.tcl)
  • 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)