On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg <sebast...@sipsolutions.net> wrote: > On Fr, 2014-02-28 at 08:47 +0000, Sturla Molden wrote: >> Anthony Scopatz <scop...@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 <sebast...@sipsolutions.net> wrote: > On Fr, 2014-02-28 at 08:47 +0000, Sturla Molden wrote: >> Anthony Scopatz <scop...@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@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion