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

[Francesc A. <fa...@py...>]

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