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
On Thu, Oct 2, 2014 at 6:27 PM, Sebastian Wagner se...@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.
On 1 Oct 2014 04:30, Stephan Hoyer sho...@gmail.com wrote:
On Tue, Sep 30, 2014 at 1:22 PM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
On more careful reading of your words, I think we agree; indeed, if
keys() is present is should return an iterable; but I don't think it should
be
Well, the method will have to be present on all ndarrays, since structured
arrays do not have a different type from regular arrays, only a different
dtype. Thus the attribute has to be present regardless, but some Exception
will have to be raised depending on the dtype, to make it quack like the
Actually, if I remember correctly, special methods show up in the ndarray
object when the dtype is datetime64, right?
On Wed, Oct 1, 2014 at 10:13 AM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
Well, the method will have to be present on all ndarrays, since structured
arrays do not
I first proposed this on GitHub:
https://github.com/numpy/numpy/issues/5134 ; jaimefrio requested that
I bring it to this list for discussion.
My proposal is to add a keys() method to NumPy's array class ndarray.
The behavior would be to return self.dtype.names, i.e. the column
names for a
Sounds fair to me. Indeed the ducktyping argument makes sense, and I have a
hard time imagining any namespace conflicts or other confusion. Should this
attribute return none for non-structured arrays, or simply be undefined?
On Tue, Sep 30, 2014 at 12:49 PM, John Zwinck jzwi...@gmail.com wrote:
I am also +1. I have already used structured arrays to do keyword-based
string formatting. This makes sense as well. Would this enable keyword
argument expansion?
On Tue, Sep 30, 2014 at 7:29 AM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
Sounds fair to me. Indeed the ducktyping
I like this idea. But I am -1 on returning None if the array is
unstructured. I expect .keys(), if present, to always return an iterable.
In fact, this would break some of my existing code, which checks for the
existence of keys as a way to do duck typed checks for dictionary like
objects (e.g.,
So a non-structured array should return an empty list/iterable as its keys?
That doesn't seem right to me, but perhaps you have a compelling example to
the contrary.
I mean, wouldn't we want the duck-typing to fail if it isn't a structured
array? Throwing an attributeError seems like the best
On more careful reading of your words, I think we agree; indeed, if keys()
is present is should return an iterable; but I don't think it should be
present for non-structured arrays.
On Tue, Sep 30, 2014 at 10:21 PM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
So a non-structured array
On Tue, Sep 30, 2014 at 1:22 PM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
On more careful reading of your words, I think we agree; indeed, if keys()
is present is should return an iterable; but I don't think it should be
present for non-structured arrays.
Indeed, I think we do
12 matches
Mail list logo
