[SciPy-dev] Nested arrays
Fernando Perez
Fernando.Perez at colorado.edu
Wed Jan 11 03:00:14 EST 2006
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
point:
In [20]: x = empty(2, object)
In [21]: class foo:
....: def hi(self):
....: return 'hi'
....:
....:
In [22]: x[0] = foo()
In [23]: x[1] = foo()
In [24]: x[0].hi()
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent
call last)
/home/fperez/<ipython console>
AttributeError: 'object_arrtype' object has no attribute 'hi'
It gets better:
In [45]: x[0]
Out[45]: <__main__.foo instance at 0x40a38f4c>
In [46]: isinstance(x[0],foo)
Out[46]: False
These two look positively bizarre, and almost contradictory. Of course, I
understand what's happening under the hood, but I think it's an excellent
example of the 'law of leaky abstractions' at play.
For the regular datatypes, I understand the reasons behind array scalars and
can see value in that. But I really think that, if we keep the same behavior
for object arrays, the opaque proxies that come out end up making the
construction, in practice, useless.
Perhaps I'm missing something, but I'd like to at least understand your
reasoning better here, as I otherwise see this as costing us a lot.
Cheers,
f
More information about the SciPy-Dev
mailing list