is_string_like fails

Development matplotlib-devel
1

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

2

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

···

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

3

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

4

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

···

On Nov 14, 2007 1:24 PM, Michael Droettboom <mdroe@...31...> 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.