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