Cairo backend prospects

Matplotlib does use a lot of relative imports which I think

    > is bad style.

    > See PEP 8 "Style Guide for Python Code"
    > PEP 8 – Style Guide for Python Code | peps.python.org

    > - Relative imports for intra-package imports are highly
    > discouraged. Always use the absolute package path for all
    > imports. Even now that PEP 328 [7] is fully implemented in
    > Python 2.5, its style of explicit relative imports is
    > actively discouraged; absolute imports are more portable
    > and usually more readable.

I have never run into a problem with relative imports, though I don't
object to removing them. Why are they bad style and what is the danger?

    > There was a recent "Coding Guide" thread on this list
    > (which I admit I just skimmed through). Instead of
    > reinventing the wheel, how about stating at the top of
    > CODING_GUIDE that PEP 8 is the default style for
    > matplotlib, and the following notes give in-depth
    > matplotlib examples (or possibly override PEP 8 if
    > necessary).

Agreed -- I'll update the coding style section to refer to this
document, and provide a few comments in line.

JDH

I have never run into a problem with relative imports, though I don't
object to removing them. Why are they bad style and what is the danger?

I had assumed because it would not be as obvious that the imports were
local modules, but might be wrong...

Best,

Matthew

    > Matplotlib does use a lot of relative imports which I think
    > is bad style.

    > See PEP 8 "Style Guide for Python Code"
    > PEP 8 – Style Guide for Python Code | peps.python.org

    > - Relative imports for intra-package imports are highly
    > discouraged. Always use the absolute package path for all
    > imports. Even now that PEP 328 [7] is fully implemented in
    > Python 2.5, its style of explicit relative imports is
    > actively discouraged; absolute imports are more portable
    > and usually more readable.

I have never run into a problem with relative imports, though I don't
object to removing them. Why are they bad style and what is the danger?

Its because you can unwittingly end up with module name clashes. There
can be two different modules in two different directories with the same
name and you import the wrong module by mistake. It happened to me once
when I created a 'calendar.py' module and didn't realize that Python
already has a calendar module. Its hard to debug because you get a
traceback which makes no sense.

From PEP328

Rationale for Absolute Imports
In Python 2.4 and earlier, if you're reading a module located inside a
package, it is not clear whether

import foo

refers to a top-level module or to another module inside the package. As
Python's library expands, more and more existing package internal
modules suddenly shadow standard library modules by accident. It's a
particularly difficult problem inside packages because there's no way to
specify which module is meant. To resolve the ambiguity, it is proposed
that foo will always be a module or package reachable from sys.path.
This is called an absolute import.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

···

On Wed, 2007-01-10 at 11:55 -0600, John Hunter wrote:

Just wanted to chime in here --
with python 2.5, you can have your cake and eat it too:

    from .localpkg import Symbol1, Symbol2
    from . import localpkg

This disambiguates the "calendar.py" problem that you had (and that about 90% of python coders have had at least once in their lives). :slight_smile:

-Peter

···

On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:

I have never run into a problem with relative imports, though I don't
object to removing them. Why are they bad style and what is the danger?

Its because you can unwittingly end up with module name clashes. There
can be two different modules in two different directories with the same
name and you import the wrong module by mistake.