Hi, Perry, your last proposal sounds good to me. Just a couple of comments. A Dilluns 26 Juliol 2004 17:43, Perry Greenfield va escriure:
4) To address the suggestions of Russell and Francesc, I'm proposing that the current "field" method now become an object (callable to retain backward compatibility) that supports: a) indexing by name or number (just like Records) b) name to attribute mapping (with restrictions). So that this means 3 ways to do things! As far as attribute access goes, I simply do not want to throw arbitrary attributes into the main object itself. The use of field is comparatively clean since it has not other public attributes. Aside from mapping '_' into spaces, no other illegal attribute characters will be mapped. (The identifier/label suggestion by Colin Williams has some merit, but on the whole, I think it brings more baggage than benefit). The mapping algorithm is such that it tries to map the attribute to any field name that has either a ' ' or '_' in the place of '_' in the attribute name. While all '_' in the name will take precedence over any other match, there will be no guaranteed order for other cases (e.g., 'x_y z' vs 'x y_z' vs 'x y z'; though 'x_y_z' would be guaranteed to be selected for field.x_y_z if present)
I guess that this mapping algorithm is weak enough to create some problems with special chars that are not suported. I'd prefer the dictionary/tuple of pairs mechanism in order to create a user-configured translation. I don't see the problem that Perry mentioned in an earlier message related with guarantying the persistence of such an object: we always have pickle, isn't it? or I'm missing something?
To summarize
Rarr.field.home_address Rarr.field['home address'] Rarr.field('home address')
Supporting Rarr.field['home address'] and Rarr.field('home address') at the same time sounds unnecessary to me. Moreover having a Rarr.field('home_address')[32] (for example) looks a bit strange, and I think Rarr.field['home_address'][32] would be better. But I repeat, this is my personal feeling. I know that dropping support of __call__() in field will make the change backward incompatible, but perhaps now is a good time to define a better interface to the RecArray object. Another possibility maybe to raise a deprecation warning for such an use for a couple of releases. Regards, -- Francesc Alted