Todd Miller wrote:
>On Fri, 2004-06-11 at 10:53, Colin J. Williams wrote:
>
>
>>Todd,
>>
>>I'm trying out objects.py from the CVS as of June 11, with PROTOTYPE=
>>1
>>
>>Suggestions and comments based on that.
>>
>>1. change the order in ObjectsArray so the __init__ becomes:
>> def __init__(self, objects=None, shape=None,
>>rank=None):
>> The thinking is that, in the absence of others, objects is the
>>argument most likely to be specified.
>>
>>
>
>I think this can go either way. For people that care, there are
>already array() and fromlist(). Subclasses can override the order. Am
>I missing something?
>
The convenience of being able to call the ObjectArray constructor
without using keywords.
For this purpose, I suggest that it's best to order the parameters in
the most likely frequency of usage.
I've found that it's not good to have a subclass with a different
signature. A generic call to a constructor is as likely to call the
subclass as the class.
>>2. add a check in __init__ to ensure that the shape is in fact
>>shape-like.
>>
>>
>
>Right now it raises a TypeError, and although it's ugly, it does at
>least trap the error and give a clue in the right direction.
>
The error traceback is rather deep and doesn't directly point to the
source of the problem.
>>3. real doc strings would be helpful. Currently, the doc strings are
>>monopolized by the doctest stuff,
>> which was not the original intent of doc strings.
>>
>>
>
>True enough. Maybe for 1.1.
>
>
This is particularly important for objects which are not elsewhere
documented, including private functions.
>>4. I wonder about the need for both rank and shape. NumArray gets
>>along fine with just shape.
>>
>>
>
>This is a new feature, and is useful in the context of object arrays
>where a sequence object is an ambiguous thing: should the sequence be
>seen as containing elements of an object array, or itself an element of
>the object array. rank lets you specify the rank of the resulting
>object array explicitly. It is also computed implicitly if not
>specified based on the first object which doesn't match the type of the
>original sequence. This is new for 1.0.
>
I hadn't spotted that rank gives one the opportunity to specify the
dimensionality of objects, but
shape provides another way of doing it.
>>5. It is assumed that objects (in __init__) is a sequence, but no
>>check to make sure that it is.
>>
>>
>
>Actually, for 1.0 I don't even think it has to be a sequence anymore.
>It's possible to make a rank-0 object array.
>
>
Yes, it is, this adds to the generality.
>>6. _byteorder is specified for NumArray, but not for ObjectArray,
>>this upsets a utility which
>> looks at array characteristics.
>>
>>
>
>_byteorder is a private attribute which doesn't make sense for
>ObjectArray. Add exception handling to the utility if it must be used
>with ObjectArrays.
>
I'll do that.
>
>
>
>>7. How is an ObjectArray better than a nested list of objects? It
>>seems to provide speedier access
>> to object pointers for larger n. It may offer the opportunity
>>to present data in a more organized
>> tabular manner. Dictionaries are better, in that they provide
>>access by means of an arbitrary key,
>> for the cost of hashing.
>>
>> NumArray appears to offer storage saving, in addition to the
>>above, but not here.
>>
>> Am I missing something?
>>
>>
>
>ObjectArrays can be indexed, manipulated, and printed like numarrays.
>ObjectArrays also work with object array ufuncs, so for instance, adding
>two ObjectArrays together implicitly applies the add builtin to each
>pair of elements. These ufuncs even support reductions and
>accumulations. This *is* a good question, but I still think
>ObjectArrays are useful in some contexts.
>
The ability to use the ufuncs is potentially good, but presumably
assumes a homogeneous ObjectArray.
We can't mix strings and dictionaries.
>
>Thanks for the feedback.
>
>Regards,
>Todd
>
>
>
Many thanks for your response. ObjectArray provides a flexible addition
to numarray.
Colin W
>
>
>
|
