[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