Travis Oliphant wrote:
The dtype object does contain what you want. In fact. It's the fields attribute of the dtype object that is a dictionary accessed by field name. Thus, to see if a field is a valid field itdentifier,
if name in t.dtype.fields:
would work (well there is a slight problem in that -1 is a special key to the dictionary that returns a list of field names ordered by offset and so would work also), but if you now that name is already a string, then no problem.
Mmh, just curious: I wonder about the wisdom of that overloading of a 'magic' key (-1). It will make thinks like for name in t.dtype.fields: return a spurious entry (the -1), and having the sorted list accessed as for name in t.dtype.fields[-1]: reads weird. I'm sure there was a good reason behind this, but I wonder if it wouldn't be better to provide this particular functionality (the list currently associated with the special -1 key) via a different mechanism, and guaranteeing that t.dtype.fields.keys() == [ list of valid names ]. It just sounds like enforcing a bit of API orthogonality here would be a good thing in the long run, but perhaps I'm missing something (I don't claim to know the reasoning that went behind today's implementation). Best, f