[SciPy-dev] Nested arrays
oliphant.travis at ieee.org
Wed Jan 11 02:26:12 CST 2006
Fernando Perez wrote:
>Travis Oliphant wrote:
>>I've committed two changes
>>1) Now all object array-scalars look to the proxied object for it's
>>mapping, sequence, and buffer behavior
>I wonder if the scalars returned by object arrays should't just be the plain,
>'unboxed' underlying object. Here, I agree with Robert that object arrays are
>special anyway, and the main purpose of using ndarrays of 'O' type is so you
>have the convenient indexing, slicing and arithmetic syntactic support of
>ndarrays. I see object arrays basically as a way of 'carrying around' a
>collection of arbitrary python objects.
>But having scalar indexing return an opaque proxy breaks almost completely
>this kind of usage, because you can't get back, in a straightforward manner,
>the things you put in the container to begin with. This should illustrate my
Frankly, I'm willing to get rid of them. I suggested that a couple of
months ago, but a few people said that having the attributes even on
object scalars was going to be useful, so I capitulated and just tried
to improve the proxying...
I suppose a more thorough discussion is warranted. I think with some
effort one could figure out how to make it always appear that the object
array-scalar type is the actual underlying object but now with the
attributes of arrays.
Repeat your example with a new-style class, to see what you get however.
In : from scipy import *
In : x = empty(2, object)
In : class foo(object):
...: def hi(self):
...: return 'hi'
In : x = foo()
In : x = foo()
In : x.hi()
In : x
Out: <__main__.foo object at 0x47ff345c>
In : isinstance(x, foo)
In : type(x)
Out: <type 'object_arrtype'>
So, at least with new-style classes we are getting something useful.
Notice that also
In : x.shape
In : x.strides
In : x.flags
So, I'm still undecided. Perhaps we can figure out why old-style
classes aren't working this way...
More information about the Scipy-dev