SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py

ryanmay@...189... wrote:

Revision: 6385
          http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
Author: ryanmay
Date: 2008-11-10 18:59:18 +0000 (Mon, 10 Nov 2008)

Log Message:
-----------
Make iterable() and is_string_like() return True/False instead of 1/0.

Agreed--good cleanup.

A larger problem is that if you index out an element from a numpy array of strings, it is a numpy string array scalar, and it is not recognized by is_string_like. I have a fix for that (not committed), but it causes breakage elsewhere. All this is an example of the perils of duck-typing; it has its advantages, but also its pitfalls.

Eric

···

Modified Paths:
--------------
    trunk/matplotlib/lib/matplotlib/cbook.py

Modified: trunk/matplotlib/lib/matplotlib/cbook.py

--- trunk/matplotlib/lib/matplotlib/cbook.py 2008-11-09 14:11:16 UTC (rev 6384)
+++ trunk/matplotlib/lib/matplotlib/cbook.py 2008-11-10 18:59:18 UTC (rev 6385)
@@ -261,16 +261,16 @@
def iterable(obj):
     'return true if *obj* is iterable'
     try: len(obj)
- except: return 0
- return 1
+ except: return False
+ return True

     'return true if *obj* looks like a string'
- if hasattr(obj, 'shape'): return 0
+ if hasattr(obj, 'shape'): return False
     try: obj + ''
- except (TypeError, ValueError): return 0
- return 1
+ except (TypeError, ValueError): return False
+ return True
  def is_sequence_of_strings(obj):
     """

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-checkins mailing list
Matplotlib-checkins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

Eric Firing wrote:

···

ryanmay@...189... wrote:

Revision: 6385
          http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
Author: ryanmay
Date: 2008-11-10 18:59:18 +0000 (Mon, 10 Nov 2008)

Log Message:
-----------
Make iterable() and is_string_like() return True/False instead of 1/0.

Agreed--good cleanup.

A larger problem is that if you index out an element from a numpy array
of strings, it is a numpy string array scalar, and it is not recognized
  by is_string_like. I have a fix for that (not committed), but it
causes breakage elsewhere. All this is an example of the perils of
duck-typing; it has its advantages, but also its pitfalls.

What's your fix, and, more importantly, what breakage does it cause?
I've added a fix locally to just check to see if the string is an
instance of np.string_. It works, along with a few other things, to fix
the scatter() problem. I was just getting ready to start running this
stuff by the list...

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:

Eric Firing wrote:

Revision: 6385
          http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
Author: ryanmay
Date: 2008-11-10 18:59:18 +0000 (Mon, 10 Nov 2008)

Log Message:
-----------
Make iterable() and is_string_like() return True/False instead of 1/0.

Agreed--good cleanup.

A larger problem is that if you index out an element from a numpy array of strings, it is a numpy string array scalar, and it is not recognized by is_string_like. I have a fix for that (not committed), but it causes breakage elsewhere. All this is an example of the perils of duck-typing; it has its advantages, but also its pitfalls.

What's your fix, and, more importantly, what breakage does it cause?
I've added a fix locally to just check to see if the string is an
instance of np.string_. It works, along with a few other things, to fix
the scatter() problem. I was just getting ready to start running this
stuff by the list...

The fix is:

def is_string_like(obj):
     """
     Return True if *obj* looks like a string

     Such objects should include Python strings, unicode
     strings, and numpy string array scalars.
     """
     #if hasattr(obj, 'shape'): return 0
     # I think the above is a legacy of Numeric...
     try:
         if str(obj) + '' == obj:
             return True
     except (TypeError, ValueError):
         return False
     return True

I am not even sure if the above is the fix we want, but having numpy string array elements fail "is_string_like" seems like a fundamentally bad thing.

Breakage is in font dictionary handling.

I don't have the whole problem solved, and I need to move on to other things right now.

Eric

···

ryanmay@...189... wrote:

Ryan

Eric Firing wrote:

The fix is:

def is_string_like(obj):
    """
    Return True if *obj* looks like a string

    Such objects should include Python strings, unicode
    strings, and numpy string array scalars.
    """
    #if hasattr(obj, 'shape'): return 0
    # I think the above is a legacy of Numeric...
    try:
        if str(obj) + '' == obj:
            return True
    except (TypeError, ValueError):
        return False
    return True

I am not even sure if the above is the fix we want, but having numpy
string array elements fail "is_string_like" seems like a fundamentally
bad thing.

I agree. It's even more egregious when you consider that:

s = numpy.string_('Foo')
isinstance(s, str)

True

I think a nicer workaround at the moment might be to just see if the
passed in object *is* indeed a string instance, and if so, return True.
I can't imagine that breaking anything. Figuring out why font
dictionary handling breaks would be good to do however.

Ryan

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

we definitely want numpy strings, eg in a record array, to return True here.

···

On Mon, Nov 10, 2008 at 1:59 PM, Ryan May <rmay31@...149...> wrote:

I am not even sure if the above is the fix we want, but having numpy
string array elements fail "is_string_like" seems like a fundamentally
bad thing.