From: Colin J. W. <cj...@sy...> - 2004-06-14 16:45:28
|
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 > > > |