Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Bruce S. <bas...@nc...>]

Maybe I'm using the word "relative" incorrectly. I'll try to be more clear:

Suppose in the site-packages/visual folder the file __init__.py has
"from visual.ui import display". That's clearly an absolute import;
the full path visual.ui is given.

In the past, you could instead say "from ui import display", and this
was called a "relative" import. It had the problem of ambiguity with
some possible module named ui, outside the visual module, and so this
form was deprecated (and I think maybe it won't even work in Python
3).

Though I only became aware of this recently, since at least Python 2.6
you can say "from .ui import display", where the dot makes this an
absolute import, with the dot standing for "visual.". In this
conversation I incorrectly called the dot form a "relative" import,
because it is relative to the current directory. But it is really an
absolute import, one that has the advantage that changing the name of
the surrounding directory doesn't require any changes to the files.

Bruce Sherwood

On Sat, Oct 9, 2010 at 9:08 AM, Bruce Sherwood <bas...@nc...> wrote:
> I had read those same documents about imports and reached the opposite
> conclusions!
>
> The full context in your reference [1] is this:
>
> "Never use relative package imports. If you’re writing code that’s in
> the package.sub.m1 module and want to import package.sub.m2, do not
> just write import m2, even though it’s legal. Write from package.sub
> import m2 instead. Relative imports can lead to a module being
> initialized twice, leading to confusing bugs. See PEP 328 for
> details."
>
> By "relative import" here they mean "import m2" inside a package,
> which has the danger of importing some module named m2 that is outside
> the package. As I read the documents, the new dot notation is designed
> to make it possible for packages to be real packages, which can even
> be moved to a different folder and still work under the new package
> name.
>
> An example of the power of the dot notation is that for Python 3 I was
> able to make experimental versions of IDLE and VIDLE that except for
> one single very special statement don't refer to either "idlelib" or
> "vidle" and have mostly the same code inside the idlelib or vidle
> folder.
>
> If I've fundamentally misunderstood the point, perhaps a very specific
> example would help me see the error of my ways.
>
> Bruce Sherwood
>
> On Fri, Oct 8, 2010 at 5:05 PM, Guy K. Kloss <g....@ma...> wrote:
>> On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote:
>>> This proposal assumed that the "libvisual" file was in the visual
>>> folder, in which case I thought that relative imports were now
>>> favored, for various reasons. As I understand it, the main issue is
>>> that there could be a module named "foo" at a higher level in the
>>> search path, in which case "import foo" might not pick up our foo, but
>>> someone else's foo. Have I misunderstood something?
>>
>> Well, not really. It's just that the use of relative imports is mainly
>> intended for corner cases, but it's discouraged to be used on a general basis.
>> Of course, things could break if there's a clash between two "foo" modules.
>> This is called "shadowing". One common case is for example when people call a
>> variable "file" and therefore are shadowing the built-in "file" type.
>>
>> In other cases, this behaviour is exactly desired, so for example when people
>> *want* to use a specific implementation as a drop-in replacement for an
>> otherwise used package. This is for example quite common with the XML parser
>> through the ElementTree API. Many APIs are designed to be compatible with each
>> other, another one of those are the ones of the threading/processing modules.
>> So a user can choose which one to use (for various reasons).
>>
>> So what it boils down to is to commonly use absolute imports rather than
>> relative ones, unless something demands a relative import for specific
>> reasons. From the Python documentation [1]: "Relative imports can lead to a
>> module being initialized twice, leading to confusing bugs. See PEP 328 [2] for
>> details."
>>
>> You can read up more on this and related issues more on [1], [2] and [3].
>>
>> Guy
>>
>>
>> [1] http://docs.python.org/faq/programming.html#what-are-the-best-practices-
>> for-using-import-in-a-module
>>
>> [2] http://docs.python.org/release/2.5/whatsnew/pep-328.html
>>
>> [3] http://bugs.python.org/issue10031
>>
>> Guy
>>
>