matplotlib-devel

[matplotlib-devel] is_string_like fails

[Eric F. <ef...@ha...>]

step_demo is failing because of this:

In [4]:xx = numpy.ma.ones((2,3))

In [5]:xx + ''
Out[5]:array(NotImplemented)


which makes cbook.is_string_like(xx) return True.  This is a pitfall of 
duck-typing--sometimes something that quacks like duck is not a duck at all.

I can get back to this later, but maybe someone else can quickly think 
of a better non-hackish duck-typing test to use in is_string_like.

Or, maybe there are places where we need to be using
isinstance(x, (str, unicode))
instead.  Are there really cases where we need to detect something that 
is not a subclass of str or unicode, but that we can and should still 
treat as a string?

At the same time, I notice that cbook.is_file_like is identical to 
is_string_like.  This seems worse than useless to me.  If we are going 
to have "is_file_like" then it should do something like check for read 
and write methods.

Eric

Re: [matplotlib-devel] is_string_like fails

[John H. <jd...@gm...>]

On Nov 14, 2007 12:57 PM, Eric Firing <ef...@ha...> wrote:

> step_demo is failing because of this:
>
> In [4]:xx = numpy.ma.ones((2,3))
>
> In [5]:xx + ''
> Out[5]:array(NotImplemented)
>

A couple of days ago I was cleaning up references to Numeric and
numarray, and came across this

def is_string_like(obj):
    if hasattr(obj, 'shape'): return 0 # this is a workaround
                                       # for a bug in numeric<23.1
    try: obj + ''
    except (TypeError, ValueError): return 0
    return 1

Since we were no longer supporting Numeric, I figured this was
obsolete, and removed the hasattr check.  It looks like we need it
still, so I readded it to svn

> Or, maybe there are places where we need to be using
> isinstance(x, (str, unicode))
> instead.  Are there really cases where we need to detect something that
> is not a subclass of str or unicode, but that we can and should still
> treat as a string?

Yes, this comes up occasionally for people who have custom string
classes.  With the exception of my recent "fix", it has been quite
robust.

> At the same time, I notice that cbook.is_file_like is identical to
> is_string_like.  This seems worse than useless to me.  If we are going
> to have "is_file_like" then it should do something like check for read
> and write methods.

This looks like a bug.  No other part of the code even calls it, so I
removed it and noted it in API CHANGES

JDH

Re: [matplotlib-devel] is_string_like fails

[Michael D. <md...@st...>]

John Hunter wrote:
>> At the same time, I notice that cbook.is_file_like is identical to
>> is_string_like.  This seems worse than useless to me.  If we are going
>> to have "is_file_like" then it should do something like check for read
>> and write methods.
> 
> This looks like a bug.  No other part of the code even calls it, so I
> removed it and noted it in API CHANGES

Coincidentally, I just noticed this myself, and fixed it (and renamed it 
to is_writable_file_like).  There will be (once I commit), and handful 
of places that use it.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Re: [matplotlib-devel] is_string_like fails

[John H. <jd...@gm...>]

On Nov 14, 2007 1:24 PM, Michael Droettboom <md...@st...> wrote:

> Coincidentally, I just noticed this myself, and fixed it (and renamed it
> to is_writable_file_like).  There will be (once I commit), and handful
> of places that use it.

By the way, your changes to make all the backends support writing to
file-like objects is really nice.  This is a *long* standing request,
particularly for web application developers, and will be very useful.
I was never able to figure out how to trick libpng into doing what I
wanted.

JDH