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