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