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

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

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
>