Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Colin J. W. <cj...@sy...>]

Russell E Owen wrote:

> At 5:41 PM -0400 2004-07-26, Colin J. Williams wrote:
>
>> Russell E Owen wrote:
>>
>>>  At 11:43 AM -0400 2004-07-26, Perry Greenfield wrote:
>>>
>>>>  I'll try to see if I can address all the comments raised (please 
>>>> let me know
>>>>  if I missed something).
>>>>  ...(nice proposal elided)...
>>>>  Any comments on these changes to the proposal? Are there those 
>>>> that are
>>>>  opposed to supporting attribute access?
>>>
>>>
>>>
>>>  Overall this sounds great.
>>>
>>>  However, I am still strongly against attribute access.
>>>
>>>  Attributes are usually meant for names that are intrinsic to the 
>>> design of an object, not to the user's "configuration" of the object.
>>
>>
>> Russell, I hope that you will elaborate this distinction between 
>> design and usage.  On the face of it, I would have though that the 
>> two should be closely related.
>
>
> To my mind, the design of an object describes the intended behavior of 
> the object: what kind of data can it deal with and what should it do 
> to that data. It tends to be "static" in the sense that it is not a 
> function of how the object is created or what data is contained in the 
> object. The design of the object usually drives the choice of the 
> attributes of the object (variables and methods).
>
> On the other hand, the user's "configuration" of the object is what 
> the user has done to make a particular instance of an object unique -- 
> the data the user has been loaded into the object.
>
> I consider the particular named fields of a record array to fall into 
> the latter category. But it is a gray area. Somebody else might argue 
> that the record array constructors is an object factory, turning out 
> an object designed by the user. From that alternative perspective, 
> adding attributes to represent field names is perhaps more natural as 
> a design.
>
> I think the main issues are:
> - Are there too many ways to address things? (I say yes) 

This could be true.  I guess the test is whether there is a rational 
justification for each way.

>
> - Field name mapping: there is no trivial 1:1 mapping between valid 
> field names and valid attribute names. 

If one starts with the assumption that field/attribute names are 
compatible with Python names, then I don't see that this is a problem.  
The question has been raised as to whether a wider range of names should 
be permitted e.g.. including such characters as ~`()!çéë.  My view is 
that such characters should be considered acceptable for data labels, 
but not for data names. i.e. they are for display, not for manipulation.

>
> - Nested access. Not sure about this one, but I'd like to hear more. 

A RecArray is made of of a number of records, each of the same length 
and data configuration.  Each field of a record is of fixed length and 
type.  It wouldn't be a big leap to permit another record in one of the 
fields.

Suppose we have an address record aRec and a personnel record pRec and 
that rArr is an array of pRec.
aRec
  street: a30
  city:a20
  postalCode: a7

pRec
  id: i4
  firstName: a15
  lastName: a20
  homeAddress: aRec
  workAddress: aRec

Then rArr[16].homeAddress.city could give us the hime city for person 16 
in rArr

>
>
> If we do end up with attributes for field names, I really like Rick 
> White's suggestion of adding an attribute for a field only if the 
> field name is already a valid attribute name. That neatly avoids the 
> collision issue and is simple to document.
>
> -- Russell 

Best wishes,

Colin W.

>
>