[Numpy-discussion] ndarray is not a sequence

[Robert Kern]

On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg
<sebastian at sipsolutions.net> wrote:
> On Fr, 2014-02-28 at 08:47 +0000, Sturla Molden wrote:
>> Anthony Scopatz <scopatz at gmail.com> wrote:
>> > Hello All,
>> >
>> > The semantics of this seem quite insane to me:
>> >
>> > In [1]: import numpy as np
>> >
>> > In [2]: import collections
>> >
>> > In [4]: isinstance(np.arange(5), collections.Sequence) Out[4]: False
>> >
>> > In [6]: np.version.full_version
>> > Out[6]: '1.9.0.dev-eb40f65'
>> >
>> > Is there any possibility that ndarray could inherit (in the last place)
>> > from collections.Sequence?  It seems like this would only be a 1 - 5 line
>> > fix somewhere.  I just spent a few hours tracking down a bug related to
>> > this.  Thanks for considering!
>>
>> This should be very easy to do. But what would this give us, and what would
>> the extra overhead be? collections.Sequence is basically an abstract base
>> class. If this just slows down ndarray it would be highly undesirable. Note
>> that ndarray has a very specific use (numerical computing). If inheriting
>> collections.Sequence has no benefit for numerical computing it is just
>> wasteful overhead. In this resepect ndarray is very different for other
>> Python containers in that they have no specific use and computational
>> performance is not a big issue.
>
> There is no overhead for the array itself.

Right, since it's an abstract base class, we don't need to subclass
from Sequence, just register ndarray with it.

> The biggest concern is about
> corner cases like 0-d arrays.

I think it's reasonable to allow it. The pre-ABC way to check this
kind of thing also gives a false positive on 0-d arrays, so we're not
regressing.

[~]
|1> import operator

[~]
|2> operator.isSequenceType(np.array(5))
True

> That said we probably need to do it anyway
> because the sequence check like that seems standard in python 3. There
> is an issue about it open on github with some discussion about this
> issue.

https://github.com/numpy/numpy/issues/2776

Also, while we're doing this, we should also register the scalar types
with their appropriate ABCs:

  numbers.Real.register(np.floating)
  numbers.Integral.register(np.integer)
  numbers.Complex.register(np.complexfloating)

-- 
Robert Kern

On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg
<sebastian at sipsolutions.net> wrote:
> On Fr, 2014-02-28 at 08:47 +0000, Sturla Molden wrote:
>> Anthony Scopatz <scopatz at gmail.com> wrote:
>> > Hello All,
>> >
>> > The semantics of this seem quite insane to me:
>> >
>> > In [1]: import numpy as np
>> >
>> > In [2]: import collections
>> >
>> > In [4]: isinstance(np.arange(5), collections.Sequence) Out[4]: False
>> >
>> > In [6]: np.version.full_version
>> > Out[6]: '1.9.0.dev-eb40f65'
>> >
>> > Is there any possibility that ndarray could inherit (in the last place)
>> > from collections.Sequence?  It seems like this would only be a 1 - 5 line
>> > fix somewhere.  I just spent a few hours tracking down a bug related to
>> > this.  Thanks for considering!
>> >
>>
>> This should be very easy to do. But what would this give us, and what would
>> the extra overhead be? collections.Sequence is basically an abstract base
>> class. If this just slows down ndarray it would be highly undesirable. Note
>> that ndarray has a very specific use (numerical computing). If inheriting
>> collections.Sequence has no benefit for numerical computing it is just
>> wasteful overhead. In this resepect ndarray is very different for other
>> Python containers in that they have no specific use and computational
>> performance is not a big issue.
>>
>
> There is no overhead for the array itself. The biggest concern is about
> corner cases like 0-d arrays. That said we probably need to do it anyway
> because the sequence check like that seems standard in python 3. There
> is an issue about it open on github with some discussion about this
> issue.
>
> - Sebastian
>
>
>> Sturla
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



-- 
Robert Kern