[Numpy-discussion] Proposal: add ndarray.keys() to return dtype.names

[John Zwinck]

On Thu, Oct 2, 2014 at 6:27 PM, Sebastian Wagner <sebix at sebix.at> wrote:
> So, for non-structured arrays, the consens is an Exception. The question
> is, which one.
> AttributeError would be fully backwards compatible. Existing code checks
> for the method and if it exists, the object has fields.
> ValueError would make more sense, as the value - the array - is in wrong
> format/structure/type.

If a non-structured array has its keys() raise AttributeError, I think
that hasattr(arr, "keys") should return False, which implies that
getattr(arr, "keys") should throw AttributeError.  This would require
that ndarray.__getattribute__ raise AttributeError, meaning "the
attribute isn't here," not merely "the attribute doesn't have a value
now."  Otherwise people may rightly complain when they interrogate an
array to see if it has keys(), find out that it does, but then get an
error upon calling it which could have been known ahead of time.

Now, to actually implement it this way would seem to require setting
the "tp_getattro" function pointer
(https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_getattro).
Currently PyArray_Type has this field as null.  If I understand
everything correctly, adding a non-null function pointer here would
mean some small runtime overhead to resolve every attribute on
ndarray.  I could easily be missing some detail which would allow us
to do what I described above without a performance hit, but someone
better versed would need to explain how/why.

If I'm right about all that, and if the consensus is that keys()
should raise an exception when dtype.names is None, then perhaps
raising ValueError is the only viable option.

I'd appreciate opinions from those experienced in the details of the C API.