Thread: Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py

ry...@us... 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
>  
>  
>  def is_string_like(obj):
>      '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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

Ryan May wrote:
> Eric Firing wrote:
>> ry...@us... 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

> 
> 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

On Mon, Nov 10, 2008 at 1:59 PM, Ryan May <rm...@gm...> 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.

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

Eric Firing wrote:
> ry...@us... 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