Polygon examples broken

Development matplotlib-devel
1

I just noticed that the example poly_editor.py is broken. It appears to be the Artist.update_from(self.line, poly) that is called when the polygon is changed. The problem is that no change is saved after a subsequent modification.

Also, clippath_test.py (that also uses Polygons) appears to be broken as well, but I'm not sure where to look for the bug...

Also, while I am writing, there are two other things I have been meaning to mention:

First, it has bothered me that from pylab import * and from numpy import * both import 'load' statements. Yes, I realize that I can put them in their own name space, but I only use python for mpl and numpy -- for me python is a matlab replacement. So, I have come to the realization that these two things (alone) I want in my top namespace. It would be nice if they didn't conflict.

Second, much of what I do involves plotting model data (on a curvilinear grid). I generally like to use pcolor for these plots. I *always* want shading='flat' Some of my grids are large, and I only see lines if I don't. Even with smaller grids, those black lines get in the way. I don't want to suggest an RC setting for everything, but this one single setting would save me thousands of characters typed per week. Can we add an RC shading option?

-Rob

···

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

2

Rob Hetland wrote:

First, it has bothered me that from pylab import * and from numpy import * both import 'load' statements. Yes, I realize that I can put them in their own name space, but I only use python for mpl and numpy

That's why: "Namespaces are one honking great idea". They really are. Trust me on this.

Also, doesn't pylab hold all of numerix anyway? Why do you need both?

If you want to use the latest numpy API (which I do) then again -- "Namespaces are one honking great idea". This is what they are for.

Otherwise, you're stuck with using numerix and waiting until MPL goes pure numpy ( I don't know when that might be). pylab and numpy stomp all over each other (if you use import *) by design.

It comes down to this: if you use "import *" you're forced to use the decision made by others -- the numerix API, which, quite reasonably, they are keeping backward compatible.

Is it really that hard to use this?

import numpy as N # or "as npy", the mpl standard.

a = N.arange(10)

a.sum()

etc, etc...

One of the nice things about numpy is that there are lot more array methods, rather than functions, so it works better with namespaces -- you really don't need to type the "N." all that much.

from pylab import *
import numpy as N

May be a reasonable compromise.

> -- for me python is a matlab replacement.

In many ways it is for me too, but it's so much better! take advantage of the advantages -- like namespaces.

If you're anything like me, you may not be writing big programs, but even quickie scripts are edited and re-edited a lot -- a little extra typing makes little difference.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

3

I get namespaces. They are really great. It's just that I use numpy and mpl *so* much that the namespaces get in the way. Most of my (smaller) coding errors involve forgetting 'pl.' in front of an mpl function.

There is also quite a bit of advice on the internet and otherwise that 'from numpy import *' is the way to import the library. For example, this is the approach in Oliphant's 'Guide to Numpy.'

And really, numpy and mpl coexist beautifully, except for a few small exceptions. 'load' is one. (There are others I have run across as well).

I think mpl should play nice even for folks like me who occasionally like to abandon separate namespaces.

-Rob

···

On Jul 20, 2007, at 2:02 PM, Christopher Barker wrote:

That's why: "Namespaces are one honking great idea". They really are.
Trust me on this.

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

4

Rob Hetland wrote:

There is also quite a bit of advice on the internet and otherwise
that 'from numpy import *' is the way to import the library. For
example, this is the approach in Oliphant's 'Guide to Numpy.'

You'll often see it in examples because it's the only way to make examples clear
and to the point. It's not a recommendation.

···

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
  -- Umberto Eco

5

Robert Kern wrote:

Rob Hetland wrote:

There is also quite a bit of advice on the internet and otherwise that 'from numpy import *' is the way to import the library. For example, this is the approach in Oliphant's 'Guide to Numpy.'

You'll often see it in examples because it's the only way to make examples clear
and to the point. It's not a recommendation.

Indeed. way back when, in the days of Numeric, it WAS the recommendation, then we were in a state of flux, and as Robert said, many quick examples are still written using "import *".

However, I have seen a real shift on the numpy list over the last year (or two), toward using the namespace.

Paul Kienzle wrote:

Out of 491 names in the numpy namespace, I found 26 that would commonly be found in math expressions.

The C99 math/complex headers define a number of symbols.

Sure, but you don't need all of those. My idea was thus:

"Namespaces are one honking great idea"

but they are kind of ugly inside math expressions. But:

"Practicality beats purity"

so I think it does make sense to bring the common names that show up in math expressions into the main namespace. Not all the handy little names ( like isnan, zeros, linspace, etc.) only the ones that show up in the depths of nested math expressions, so that we can write code that looks like math. That's how I came up with my personal list of 26.

This is probably best just done by each individual according to his/her taste.

Rob Hetland wrote:

I get namespaces. They are really great. It's just that I use numpy and mpl *so* much that the namespaces get in the way.

Maybe using Paul's suggestion of having a "math" namespace that you "import *" would help.

Or use "from pylab import *" and reference just the numpy names you want separately.

And really, numpy and mpl coexist beautifully, except for a few small exceptions. 'load' is one. (There are others I have run across as well).

I think mpl should play nice even for folks like me who occasionally like to abandon separate namespaces.

But it does. numpy was designed pretty much to do just that -- give you one big namespace to import. And it provides the numerix interface as part of that.

However, if you do that, you have to deal with the decisions MPL developers make. numpy is designed by a separate team, and is not designed to be "import *"ed into the pylab namespace (I think it is designed not to clash with the python built-ins at least). This is a common issue with packages developed by different people for similar purposes, and python already has namespaces as a great way to deal with it!

Indeed, in this case, I suppose it's the numpy folks that aren't "playing nice" -- numpy.load was added after pylab.load was already there. But it's not a goal of the numpy team to be name-compatible with pylab.

-Chris

This is really is pretty OT for the devel list, though, so I'll stop here.

···

On Fri, Jul 20, 2007 at 12:34:44PM -0700, Christopher Barker wrote:

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

6

Yes, I do that to, primarily in scripts. However, for interactive sessions, I usually import into the top namespace. I imagine others might as well. Particularly people coming from environments like matlab will initially want everything up top.

Separate namespaces are great. I still think from
  pylab import *
should not overlap with from
  numpy import *

I don't think it would be hard to make sure that there are no duplicate function names in the top namespace. E.g., mpl load could be put in mpl, matplotlib, or mpl_io, or something similar.

People will migrate to separate namespaces eventually, as they get more familear with python, but they will be annoyed initially with any overlaps.

-Rob

···

On Jul 20, 2007, at 5:53 PM, Christopher Barker wrote:

However, I have seen a real shift on the numpy list over the last year
(or two), toward using the namespace.

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331