from __future__ import absolute_import ?

[Ron Adam]

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