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.kern@gmail.com> wrote: On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote: > On Fr, 2014-02-28 at 08:47 +0000, Sturla Molden wrote: >> Anthony Scopatz <scopatz@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@sipsolutions.net> wrote: > On Fr, 2014-02-28 at 08:47 +0000, Sturla Molden wrote: >> Anthony Scopatz <scopatz@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