[SciPy-user] 'object_arrtype' problem
ryanlists at gmail.com
Thu Dec 8 13:13:50 CST 2005
One thing I don't like about Numeric returning the object is that
things get a little messy when you aren't sure if you have an array or
not. I find myself calling atleast_1d a lot or writing tests using
"if shape(obtject)" which returns an empty tuple for scalars. I guess
my thoughts are slightly twisted by everything being an array in
Matlab. I want to test if len==1, then it must be a scalar. I guess
I would be happiest with clean scalar tests and objects that worked
well when iterating or indexing from an object array.
On 12/8/05, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> Ryan Krauss wrote:
> >What do you mean by "hand off behavior of the object to the underlying
> >object in all cases"?
> All arrays return array scalars. This allows us to control the math and
> the methods of the returned objects. This is very useful for the
> regular arrays. Object arrays simply inherited that behavior and
> therefore there is an "object"-array type. (Run type() on one of your
> returned objects...) In this case, though, the array object contains a
> pointer to another object (that's the thing that has the methods and
> attributes you wanted).
> There is the obvious question as to whether or not having a separate
> object array-scalar type is even useful, though. It does provide
> consistency of behavior but I think the expense is too high in this case.
> Right now, I'm leaning to having OBJECT arrays return the actual object
> like Numeric did. This will mean, of course that they won't have the
> array methods and there will be an "except-for object arrays" cluttered
> throughout documentation, but I think it's a better compromise solution .
> The change is not difficult and could be done in about 30 minutes.
> I'd like to hear from people as to what their attitude is:
> 1) Have object arrays return the actual Python object like Numeric did
> but different from all other array types which return an "array-scalar"
> 2) Keep the current behavior but soup up the object array type so it
> "works better". I don't think we could ever make a generic object that
> can always respond as any other object, though, so there will be minor
> issues regardless.
> Let me know.
> SciPy-user mailing list
> SciPy-user at scipy.net
More information about the SciPy-user