PEP 328 update

[Aahz]

PEP 328 (``import`` changes) has been updated and is available at
http://www.python.org/peps/pep-0328.html

Comments on the revised version are welcome. One area where feedback is
particularly desired is on the frequency of relative imports inside
packages in current code, both in absolute terms and as a percentage of
all imports.

 

[Scott David Daniels]

PEP 328 (``import`` changes) has been updated and is available at
http://www.python.org/peps/pep-0328.html

Comments on the revised version are welcome. One area where feedback is
particularly desired is on the frequency of relative imports inside
packages in current code, both in absolute terms and as a percentage of
all imports.

I am unclear as to why "import ..moduleA as A" is not allowed. The only
rationale given for disallowing relative imports like "import .foo" is
that .foo is unacceptable as a name. I'd propose a mandatory AS-clause
if the MODULE begins with a period.

This would allow me to do something like "import . as mypackage" -- a
case which is perhaps unnecessary. I just found the "must use the
from-style imports" surprising (I agree the change is not vital).

 

[Aahz]

I am unclear as to why "import ..moduleA as A" is not allowed. The only
rationale given for disallowing relative imports like "import .foo" is
that .foo is unacceptable as a name. I'd propose a mandatory AS-clause
if the MODULE begins with a period.

This would allow me to do something like "import . as mypackage" -- a
case which is perhaps unnecessary. I just found the "must use the
from-style imports" surprising (I agree the change is not vital).

I'm no expert, but I'd bet that Python's grammar can't support this.
Someone will be by to correct me if I'm wrong. ;-)

 

[Carl Banks]

PEP 328 (``import`` changes) has been updated and is available at
http://www.python.org/peps/pep-0328.html

Comments on the revised version are welcome. One area where feedback is
particularly desired is on the frequency of relative imports inside
packages in current code, both in absolute terms and as a percentage of
all imports.

I have one app with an ornate package system that uses relative
imports all over the place (it's pretty much 100% of package imports
for that package). Also, in most of my typical freestanding unitary
packages without subpackages, modules typically import sister modules
relatively. So, for me, relative imports are very common.

In light of this, I'll probably change them all to absolute imports.

 

[John Roth]

PEP 328 (``import`` changes) has been updated and is available at
http://www.python.org/peps/pep-0328.html

Comments on the revised version are welcome. One area where feedback is
particularly desired is on the frequency of relative imports inside
packages in current code, both in absolute terms and as a percentage of
all imports.

What worries me about the PEP is the way it breaks backwards
compatability. I'd much rather see some kind of decorator (possibly
an !) to indicate an absolute import, and leave the undecorated form
exactly the way it is, at least until 3.0.

I also don't particularly see the reason for banning the relative form
from raw import statements.

The other two changes are, of course, welcome.

John Roth

 

[Aahz]

I also don't particularly see the reason for banning the relative form
from raw import statements.

Did you see the rationale toward the end?

 

[John Roth]

Did you see the rationale toward the end?

Yes. From my point of view, the . is an operator or a
decorator. It is not a part of the name; if it was, the
system would be unable to find the module on disk,
because that name does not have the dot.

The rationale makes no sense whatsoever.

John Roth

 

[Carl Banks]

Yes. From my point of view, the . is an operator or a
decorator. It is not a part of the name; if it was, the
system would be unable to find the module on disk,
because that name does not have the dot.

The rationale makes no sense whatsoever.

Look at it this way:

If you do "import abc.def.ghi", then the module ghi gets imported
(along with packages abc and def); however, only the only symbol that
gets bound is "abc".

If you try to do "import .ghi", well, it's obvious that you're
imporing a sister module, but it's not clear what symbol should be
bound. (Do you bind "ghi" or "abc"?)

According to the Python Zen: "In the face of ambiguity, refuse the
temptation to guess." Ergo, don't allow it.

But frankly, even if it were obvious, neither option makes sense. If
"import .ghi" means to bind the symbol "abc", then the code that uses
it has to know that "ghi" is found in package "abc.def". That pretty
much defeats the purpose of relative imports. It also makes the code
incredibly unclear to the reader.

If "import .ghi" means to bind the symbol "ghi", well, there's already
a way to do it, namely "from . import ghi". And there should only be
one way to do it.

 

[Michael Hudson]

I'm no expert, but I'd bet that Python's grammar can't support this.
Someone will be by to correct me if I'm wrong. ;-)

I think you can do this via the usual 'accept too much in the grammar
and throw things out in the compiler' dance.

Cheers,
mwh

 

[John Roth]

Look at it this way:

If you do "import abc.def.ghi", then the module ghi gets imported
(along with packages abc and def); however, only the only symbol that
gets bound is "abc".

If you try to do "import .ghi", well, it's obvious that you're
imporing a sister module, but it's not clear what symbol should be
bound. (Do you bind "ghi" or "abc"?)

Why isn't it clear? The way it currently works, if you use
import foo, the name being bound is foo. I see no reason to
change that. If you want something other than the first name in
the string to be bound, then you use the from syntax.

According to the Python Zen: "In the face of ambiguity, refuse the
temptation to guess." Ergo, don't allow it.

What's to guess? You're just complicating things for no good
reason that I can discern.

But frankly, even if it were obvious, neither option makes sense. If
"import .ghi" means to bind the symbol "abc", then the code that uses
it has to know that "ghi" is found in package "abc.def". That pretty
much defeats the purpose of relative imports. It also makes the code
incredibly unclear to the reader.

Which is why I am astonished that anyone would consider that
seriously for more than about 10 nanoseconds.

If "import .ghi" means to bind the symbol "ghi", well, there's already
a way to do it, namely "from . import ghi". And there should only be
one way to do it.

There is a concept called "conceptual integrity." Paying close
attention to it is widely regarded as one way of making things
comprehensible by eliminating special cases. This is a special
case that I can see no compelling reason for. The only reasons
given so far don't seem credible.

John Roth

 

[Carl Banks]

Why isn't it clear?

Because some people see the little dot there and mentally expand it to
an indeterminate package name. This is a valid way to look at it.
And, if you look at it like that, "import .ghi" binding "ghi" is
inconsistent with how import normally works. Import never binds the
module name when there's a package present; why should it start now?

The point is, there is more than one way to conceive this. Your way
of looking at it is valid, but your way is not the only way. If you
are capable of accepting other viewpoints other than your own, then
maybe you can see why "import .ghi" is not clear. OTOH, "from .
import ghi" is totally clear and unambiguous.

I say the PEP correctly opts for clarity and lack of reduncancy.

 

[Greg Ewing]

you can see why "import .ghi" is not clear. OTOH, "from .
import ghi" is totally clear and unambiguous.

But surely "import .ghi as jkl" is just as clear and
unambiguous? Why shouldn't *that* be allowed?

 

[Carl Banks]

But surely "import .ghi as jkl" is just as clear and
unambiguous? Why shouldn't *that* be allowed?

Insofar as it corresponds to the way absolute imports work, I don't
really have a problem with it. It's still redundant ("from . import
fhi as jkl" does the same thing), but I'm more bothered by unclarity.

I'm not so sure the corresponding absolute import is right though,
although it's definitely intuitive. Hell, I'm not so sure "import
abc.def.ghi" binding "abc" is right.

 

[Aahz]

But surely "import .ghi as jkl" is just as clear and unambiguous? Why
shouldn't *that* be allowed?

You'd have to ask on python-dev; despite MWH's comment, I still suspect
that Python's grammar won't support it. If Guido okays it, I'm happy to
add it.

 

[Dieter Maurer]

What worries me about the PEP is the way it breaks backwards
compatability. I'd much rather see some kind of decorator (possibly
an !) to indicate an absolute import, and leave the undecorated form
exactly the way it is, at least until 3.0.
+1

I also don't particularly see the reason for banning the relative form
from raw import statements.

+1

 

[Bernhard Herzog]

PEP 328 (``import`` changes) has been updated and is available at
http://www.python.org/peps/pep-0328.html

Comments on the revised version are welcome.

pep-0328:

In Python 2.5, any ``import`` statement that results in an
intra-package import will raise ``DeprecationWarning``

Phrased like that it would seem that absolute imports referring to a
sibling module will be deprecated too

One area where feedback is
particularly desired is on the frequency of relative imports inside
packages in current code, both in absolute terms and as a percentage of
all imports.

A while back I've written a script for this. Unfortunately, I have had
very little time for Python related things in the last few months and I
never got around to post it or the statistics I gathered with it. I've
made the script available now at
http://intevation.de/~bh/python/importstat.py

What the script looks at is the relationship between the importing
module and the imported module *regardless of the spelling of the
import*. The last is important since it means that "import bar" and
"import foo.bar" will be considered the same if they refer to the same
module. The reason for this is that I wrote it to demonstrate that it
is very common to refer to other modules in the same package or the same
hierarchy. It shouldn't be hard to modify the script to account for the
spelling as well.


The script distinguishes three kinds of imports:

- Imports of modules in the same package. E.g. a.b.c imports a.b.x

- Imports of modules in the same hierarchy but not the same package
E.g. a.b.c imports a.x.y

- absolute imports i.e. imports of modules somewhere else on sys.path.
E.g. a.b.c imports z


Some typical results
absolute hierarchy package
email (Py 2.3) 50 0 41 (without email.test)
distutils (2.3) 145 71 70
twisted (1.0.0) 544 439 240 (without
Skencil (0.6) 199 248 222
Skencil (0.7) 175 318 205
Thuban 134 112 115


It should be clear from that that it's very common for a module in a
package to refer to other modules in the same package or the same
hierarchy. In the case of my own code, i.e. Skencil and Thuban above,
all package imports are relative imports.


Some more general comments on the pep:

I'd still don't understand why it's better to break backwards
compatibility to solve a problem that rarely occurs instead of staying
compatible by introducing a new spelling for absolute imports for those
few cases where the default behavior picks the wrong module.

In practically all other cases where python has several nested scopes
the local scope is the default and there is special way to refer to
outer scopes. Examples for this are local variables vs. globals and
builtins, or instance variables vs. class variables. Why should this be
different for imports?

On the whole, I don't find the pep as bad as I did when I first learned
about it. It does offer some new possibilities for relative imports and
offers a solution for a rare but real problem. Still, in my eyes
especially the early versions of the pep are an example of the
carelessness with wich some core python developers toss backwards
compatibility out of the window. I'm not against breaking compatibility
when it is a clear gain for the language but it never should be done
lightly and should always result in substantial improvements in the
language that would not be possible otherwise. I don't think that's the
case for this pep, though.

Finally, I think I've found a way to deal with the incompatibilities
that minimizes their impact for me. While hacking on the importstat
script, it occurred to me that it shouldn't be hard to write an
__import__ hook that implements the old import behavior in such a way
that it could be switched on for specific package hierachies. I'll
probably end up implementing that once Python 2.5 is about to be
released so that I don't have to change practically every module in
Skencil and Thuban just to keep up with Python incompatibilities.



Bernhard

 

[Paul Boddie]

Still, in my eyes especially the early versions of the pep are an example of
the carelessness with wich some core python developers toss backwards
compatibility out of the window. I'm not against breaking compatibility
when it is a clear gain for the language but it never should be done
lightly and should always result in substantial improvements in the
language that would not be possible otherwise. I don't think that's the
case for this pep, though.

I can see the point of resolving ambiguities with imports, especially
with common module names, but then I understand your frustrations with
the backward compatibility breakage and continuous feature infusion.
People go on about how Jython is important to general Python adoption
before leaving it in the dust under a thick layer of increasingly
difficult-to-justify functionality. People also state how important it
is for Python to adapt to new platforms, become faster, have a smaller
footprint, scale across multiple processors, and yet all of these
goals become steadily harder to reach as more marginal stuff gets
added to the mix.

I'm sure that various comp.lang.python contributors have scoffed,
Slashdot-style, at languages designed by committees, unaware that the
newsgroup and the various mailing lists are increasingly doing a good
job of emulating such committees quite effectively.

Paul