Francesc Alted wrote:
Hi,
I agree that numarray team's overhaul of RecArray access modes is very good and I agree most of it.
A Dimarts 20 Juliol 2004 19:14, Russell E Owen va escriure:
I think recarray[field name] is too easily confused with recarray[index] and is unnecessary.
Yeah, maybe you are right.
I suggest one of two solutions: - Do nothing. Make users use field(field name or index) or - Allow access to the fields via an indexable entity. Simplest for the user would be to use "field" itself: recArr.field[1] recArr.field["abc"] (i.e. field becomes an object that can be called or can be accessed via __getitem__)
I prefer the second one. Although I know that you don't like the __getattr__ method, the field object can be used to host one. The main advantage I see having such a __getattr__ method is that I'm very used to press TAB twice in the python console with its completion capabilities activated. It would be a very nice way of interactively discovering the fields of a RecArray object. I don't know whether this feature is used a lot or not out there, but for me is just great. I understand, however, that having to include a map to suport non-vbalid python names for field names can be quite inconvenient.
Regards,
Perry's issue 3. Perhaps there is a need to separate the name or identifier of a column in a RecArray or a field in a Record from its label. The labels, for display purposes, would default to the column names. The column names would default, as at present, to the Cn form. I like the use of attributes for the column names, it avoids the problem Russell Owen mentioned above. Suppose we have a simple RecArray with the fields "name" and "age", it's much simpler to write rec.name or rec.age that rec["name"] or rec["age"]. The problems with the use of attributes, which must be Python names, are (1) they cannot have accented or special characters eg é, ç, @, & * etc. and (2) there is a danger of conflict with existing properties or attributes. My guess is that the special characters would be required primarily for display purposes. Thus, the label could meet that need. The danger of conflict could be addressed by raising an exception. There remains a possible problem where identifiers are passed on from some other system, perhaps a database. Thus, the primary identifier of a row in a RecArray would be an integer index and that of a column or field would be a standard Python identifer. Although, at times, it would be useful to be able to index the individual fields (or columns) as part of the usual indexing scheme. Thus rec[2, 3, 4] could identify a record and rec[2, 3, 4].age or rec[2, 3, 4, 5] could identify the sixth field in that record. The use of attributes raises the possibility that one could have nested records. For example, suppose one has an address record: addressRecord streetNumber streetName postalCode ... There could then be a personal record: personRecord ... officeAddress homeAddress ... One could address a component as rec.homeAddress.postalCode. Finally, there was mention, earlier in the discussion, of facilitating the indexing of a RecArray. I hope that some way will be found to do this. Colin W.