Thanks All, I am sorry I missed the issue. (I still can't seem to find it, actually.) I agree that there would be minimal overhead here and I bet that would be easy to show. I really look forward to seeing this get in!
Be Well Anthony On Fri, Feb 28, 2014 at 4:59 AM, Robert Kern <robert.k...@gmail.com> wrote: > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
