[SciPy-dev] Nested arrays

Fernando Perez Fernando.Perez at colorado.edu
Wed Jan 11 02:00:14 CST 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 

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.



More information about the Scipy-dev mailing list