[SciPy-user] 'object_arrtype' problem

[Ryan Krauss]

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.

Ryan

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"
> type.
>
> 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.
>
> -Travis
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>