On Nov 14, 2007 12:57 PM, Eric Firing <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
