reverting changes to contour.py

Hi,

Sorry about the problems. The labeling code is somewhat difficult to
understand and I was using label indices when I should have used level
indices (or vice-versa). I have a fix, but want to test it more before
committing. Let me know when is a good time to do it so that I don't
mess up a release.

Cheers,
David

···

On Sat, 2008-07-19 at 19:30 -0700, matplotlib-devel-request@lists.sourceforge.net wrote:

David,

I am reverting your changes to contour.py; that is, I am taking it
back
to 5689. The problem is that running contour_demo.py, below, fails.
Some index accounting somewhere is getting fouled up. I don't have
time
to investigate.

When you have it straightened out you can put the changes back, so
this
is just a brief setback.

We might want to consider, however, whether such extensive changes
should be made immediately *before* a "bugfix" release. I think John
is
trying to get one out. I am already a little nervous about other
recent
and impending changes in this context. (Your idea of a branch was a
good one in concept, but maybe a pain and more trouble than it is
worth
with svn. Too bad we aren't using something nice like Mercurial.
Now,
that comment should push a few buttons.)

Eric

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

David M. Kaplan wrote:

Hi,

Sorry about the problems. The labeling code is somewhat difficult to
understand and I was using label indices when I should have used level
indices (or vice-versa). I have a fix, but want to test it more before
committing. Let me know when is a good time to do it so that I don't
mess up a release.

It sounds like there is time to do it before the release without messing up the release. Just make sure the backend_drivers.py test suite still runs OK. If you can add tests (i.e., examples run by backend_drivers) that exercise the new functionality, that is even better. The interactive part of the functionality can't be tested in an automated way, but the rest can, and adding an example is a good way to help users see how to use it. In any case, go ahead and commit when ready.

Yes, the labeling code is difficult, and I have not looked at it in a long time. If you are interested, please do look at it from the standpoint of a possible major revision that might make it easier to understand and easier to enhance.

Eric

···

Cheers,
David

On Sat, 2008-07-19 at 19:30 -0700, > matplotlib-devel-request@lists.sourceforge.net wrote:

David,

I am reverting your changes to contour.py; that is, I am taking it
back to 5689. The problem is that running contour_demo.py, below, fails. Some index accounting somewhere is getting fouled up. I don't have
time to investigate.

When you have it straightened out you can put the changes back, so
this is just a brief setback.

We might want to consider, however, whether such extensive changes should be made immediately *before* a "bugfix" release. I think John
is trying to get one out. I am already a little nervous about other
recent and impending changes in this context. (Your idea of a branch was a good one in concept, but maybe a pain and more trouble than it is
worth with svn. Too bad we aren't using something nice like Mercurial.
Now, that comment should push a few buttons.)

Eric

Hi,

It sounds like there is time to do it before the release without messing
up the release. Just make sure the backend_drivers.py test suite still
runs OK. If you can add tests (i.e., examples run by backend_drivers)
that exercise the new functionality, that is even better. The
interactive part of the functionality can't be tested in an automated
way, but the rest can, and adding an example is a good way to help users
see how to use it. In any case, go ahead and commit when ready.

I have recommitted my changes to contour.py plus modifications to fix
the problems you identified (r5799). I also included a couple of new
pylab_examples that test the new interactive (ginput, etc.) and
non-interactive (e.g., using a dictionary to specify label format)
elements. The non-interactive pylab_example (contour_label_demo) has
been integrated into backend_driver.py. This should hopefully help save
me from myself.

Yes, the labeling code is difficult, and I have not looked at it in a
long time. If you are interested, please do look at it from the
standpoint of a possible major revision that might make it easier to
understand and easier to enhance.

For the moment, I have tried to add a few comments here and there that
explain my understanding of things and identify some problems. One
thing that should probably be fixed immediately is that the attribute
names in ContourLabeler don't meet the standards in the coding guide
(e.g., label_levels instead of clabelLevels) and are hard to understand
(e.g., cl could be contourLevels instead of clabelLevels). I would like
to fix these, but this may break user's code that depends, e.g., on
CS.cl having that name. How much should I worry about this? There are
likely few users that directly modify ContourSet properties, but you
never know. I think changing these names and adding a few comments
would at least pave the way for future improvements.

I also have a couple of general questions for the group:

1) ginput currently returns a list of tuples instead of a two-column
array of x,y coordinates. I think a numpy array is more intuitive and
saves the user having to cast to array. Is there any reason why ginput
should not return a numpy array instead of a list of tuples?

2) Can someone explain to me why is_string_like in the cbook doesn't
just do isinstance(obj,str)? Is there anything "string like" that won't
be caught be this isinstance call?

Cheers,
David

···

On Sun, 2008-07-20 at 08:09 -1000, Eric Firing wrote:

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

In [65]: s = u'jdh'

  In [66]: isinstance(s, str)
  Out[66]: False

  In [67]: isinstance(s, unicode)
  Out[67]: True

So we could check for str or unicode, but a user may be using a custom
string like class from some c++ extension code that is part of a large
in house API. The point is that we don't care if it *is* a string, we
just want it to act like a string

  http://en.wikipedia.org/wiki/Duck_typing

···

On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <David.Kaplan@...622...> wrote:

2) Can someone explain to me why is_string_like in the cbook doesn't
just do isinstance(obj,str)? Is there anything "string like" that won't
be caught be this isinstance call?

Hi,

Similar level of question: What is the policy on using scipy in
matplotlib? I want to use linear interpolation, and
simple_linear_interpolation in the cbook doesn't do what I want. I
imagine that we are trying to avoid dependence on scipy.

Thanks,
David

···

On Mon, 2008-07-21 at 08:42 -0500, John Hunter wrote:

On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <David.Kaplan@...622...> wrote:

> 2) Can someone explain to me why is_string_like in the cbook doesn't
> just do isinstance(obj,str)? Is there anything "string like" that won't
> be caught be this isinstance call?

  In [65]: s = u'jdh'

  In [66]: isinstance(s, str)
  Out[66]: False

  In [67]: isinstance(s, unicode)
  Out[67]: True

So we could check for str or unicode, but a user may be using a custom
string like class from some c++ extension code that is part of a large
in house API. The point is that we don't care if it *is* a string, we
just want it to act like a string

  http://en.wikipedia.org/wiki/Duck_typing

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Yes, to date we've avoided a scipy dependence, which is a nuisance for
developers, but makes installation a bit easier.

JDH

···

On Mon, Jul 21, 2008 at 10:17 AM, David Kaplan <David.Kaplan@...622...> wrote:

Similar level of question: What is the policy on using scipy in
matplotlib? I want to use linear interpolation, and
simple_linear_interpolation in the cbook doesn't do what I want. I
imagine that we are trying to avoid dependence on scipy.

John Hunter wrote:

2) Can someone explain to me why is_string_like in the cbook doesn't
just do isinstance(obj,str)? Is there anything "string like" that won't
be caught be this isinstance call?

  In [65]: s = u'jdh'

  In [66]: isinstance(s, str)
  Out[66]: False

  In [67]: isinstance(s, unicode)
  Out[67]: True

So we could check for str or unicode, but a user may be using a custom
string like class from some c++ extension code that is part of a large
in house API. The point is that we don't care if it *is* a string, we
just want it to act like a string

  http://en.wikipedia.org/wiki/Duck_typing

Sometimes we have

if is_string_like(s) and s == 'some string': do_something()

I think that as long as we know s is not None (which often is something that is being checked first) then it would be simpler, faster, and more readable to use

if str(s) == 'some string': do_something()

John, do you see any problems with this? I think str(s) is guaranteed to return a string--that is, not to fail--for any python object, correct?

Eric

···

On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <David.Kaplan@...622...> wrote:

My guess is that your code will work, but I am disinclined to remove a
check that is working and was probably added to satisfy some corner
case we are forgetting about. str can fail, BTW:

In [35]: class Evil:
   ....: def __str__(self):
   ....: raise NotImplementedError
   ....:

In [36]: evil = Evil()

In [37]: print str(evil)

···

On Mon, Jul 21, 2008 at 1:06 PM, Eric Firing <efiring@...229...> wrote:

John Hunter wrote:

On Mon, Jul 21, 2008 at 7:51 AM, David Kaplan <David.Kaplan@...622...> wrote:

2) Can someone explain to me why is_string_like in the cbook doesn't
just do isinstance(obj,str)? Is there anything "string like" that won't
be caught be this isinstance call?

In [65]: s = u'jdh'

In [66]: isinstance(s, str)
Out[66]: False

In [67]: isinstance(s, unicode)
Out[67]: True

So we could check for str or unicode, but a user may be using a custom
string like class from some c++ extension code that is part of a large
in house API. The point is that we don't care if it *is* a string, we
just want it to act like a string

http://en.wikipedia.org/wiki/Duck_typing

Sometimes we have

if is_string_like(s) and s == 'some string': do_something()

I think that as long as we know s is not None (which often is something that
is being checked first) then it would be simpler, faster, and more readable
to use

if str(s) == 'some string': do_something()

John, do you see any problems with this? I think str(s) is guaranteed to
return a string--that is, not to fail--for any python object, correct?

------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
  File "<ipython console>", line 3, in __str__
NotImplementedError