On Fr, 2014-02-28 at 09:10 -0600, Anthony Scopatz wrote: > 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! >
Best way to make sure it happens soon is to open a pull request about it ;). - Sebastian > > 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
