[Numpy-discussion] ndarray is not a sequence
Anthony Scopatz
scopatz at gmail.com
Fri Feb 28 10:10:41 EST 2014
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.kern at gmail.com> wrote:
> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140228/a36c86a5/attachment.html>
More information about the NumPy-Discussion
mailing list