[SciPy-dev] Nested arrays

Travis Oliphant oliphant.travis at ieee.org
Wed Jan 11 04:16:24 EST 2006


>Well, let me put a mean twist on this:
>
>In [10]: class foo(object):
>    ....:     flags = 'they come in all kinds of pretty colors'
>    ....:     def hi(self):
>    ....:         return 'hi'
>    ....:
>    ....:
>
>In [11]: x = empty(2, object)
>
>In [12]: x[0] = foo()
>
>In [13]: x[0].hi()
>Out[13]: 'hi'
>
>In [14]: x[0].shape
>Out[14]: ()
>
>In [15]: x[0].flags
>Out[15]: 'they come in all kinds of pretty colors'
>  
>
I'm about +0.5 for returning the underlying object all the time.

Actually, up until a few checkins ago this would have always returned 
the array attribute because they were looked for first.  And it could go 
back to this too.

>Again, I think there's too strong of a clash between the abstraction of array 
>scalar proxies and whatever object is being boxed in.  For the regular 
>datatypes I think this is OK, as you normally don't go around calling 
>3.dosomething() in Python.  But for a container meant to accept arbitrary 
>objects, I'm not convinced that the cost of this kind of shadowing and 
>blending of internal and proxy attributes is any good.
>  
>
I'm not convinced either, but I'm also not (quite) convinced that they 
should disappear.  It would actually be quite simple to leave the object 
array scalars in place but never return them.   In fact, we could make 
it a user settable option ;-) just like the default array type ;-)

>I can also see the flip side of the argument (not having to special-case code, 
>so you can always assume that x[0].shape exists).  However, I think that my 
>example above shows that this 'guarantee' is so weak as to be useless:
>  
>
I think that's why I originally chose to look for the array attributes 
first....so this guarantee would always be there.

>Basically, if you get fed an 'O' array, today all bets are off as to what's 
>going to come out of indexing a scalar element.
>
>So you might as well, at least, have the guarantee that you get what you put 
>in there to begin with, instead of the bizarre hybrid that comes out today.
>  
>
The basic OBJECT type ndarray has high likelihood of going into Python 
and you can bet that no strange hybrid will be acceptable on return.

It would be literally one-line of code to turn off the returning of the 
hybrid object arrays, so I would not hesitate to do it and then see what 
kind of complaints we get :-)

-Travis





More information about the SciPy-Dev mailing list