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.deveb40f65' 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! Be Well Anthony
Anthony Scopatz
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.deveb40f65'
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. Sturla
On Fr, 20140228 at 08:47 +0000, Sturla Molden wrote:
Anthony Scopatz
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.deveb40f65'
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 0d 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
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg
On Fr, 20140228 at 08:47 +0000, Sturla Molden wrote:
Anthony Scopatz
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.deveb40f65'
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 0d arrays.
I think it's reasonable to allow it. The preABC way to check this kind of thing also gives a false positive on 0d 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
On Fr, 20140228 at 08:47 +0000, Sturla Molden wrote:
Anthony Scopatz
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.deveb40f65'
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 0d 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
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
 Robert Kern
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
On Fr, 20140228 at 08:47 +0000, Sturla Molden wrote:
Anthony Scopatz
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.deveb40f65'
Is there any possibility that ndarray could inherit (in the last
from collections.Sequence? It seems like this would only be a 1  5
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
On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg
wrote: place) line 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 0d arrays.
I think it's reasonable to allow it. The preABC way to check this kind of thing also gives a false positive on 0d 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 Fr, 20140228 at 08:47 +0000, Sturla Molden wrote:
Anthony Scopatz
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.deveb40f65'
Is there any possibility that ndarray could inherit (in the last
from collections.Sequence? It seems like this would only be a 1  5
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
On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg
wrote: place) line 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 0d 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
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
 Robert Kern _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Feb 28, 2014 at 3:10 PM, Anthony Scopatz
Thanks All,
I am sorry I missed the issue. (I still can't seem to find it, actually.)
https://github.com/numpy/numpy/issues/2776
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!
There is *no* overhead to ndarray because you don't actually subclass.  Robert Kern
On Fr, 20140228 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
wrote: On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg wrote: > On Fr, 20140228 at 08:47 +0000, Sturla Molden wrote: >> Anthony Scopatz 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.deveb40f65' >> > >> > 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 0d arrays.
I think it's reasonable to allow it. The preABC way to check this kind of thing also gives a false positive on 0d 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
wrote: > On Fr, 20140228 at 08:47 +0000, Sturla Molden wrote: >> Anthony Scopatz 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.deveb40f65' >> > >> > 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 0d 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 >> >> _______________________________________________ >> NumPyDiscussion mailing list >> NumPyDiscussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpydiscussion >> > > > _______________________________________________ > NumPyDiscussion mailing list > NumPyDiscussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpydiscussion  Robert Kern _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
_______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Feb 28, 2014 at 10:34 AM, Chris Barker  NOAA Federal < chris.barker@noaa.gov> wrote:
Whatever happened to duck typing?
http://legacy.python.org/dev/peps/pep3119/#abcsvsducktyping
On Sat, Mar 1, 2014 at 6:09 PM, Alexander Belopolsky
On Fri, Feb 28, 2014 at 10:34 AM, Chris Barker  NOAA Federal < chris.barker@noaa.gov> wrote:
Whatever happened to duck typing?
http://legacy.python.org/dev/peps/pep3119/#abcsvsducktyping
Sure  but I'm afraid that there will be a lot of code that does an isinstance() check where it it absolutely unnecessary. If you really need to know if something is a sequence or a mapping, I suppose it's required, but how often is that? I suppose there are two sides to this coin: 1) Should numpy arrays use the ABC properly so that client code will recognise them as sequences  probably, yes  why not? (though the trick here is that numpy arrays do act differently than other mutable sequences  view semantics and all  so I think it's kind of dangerous) 2) If you are writing client code, should you use an isinstance() check passedin objects?  probably not! CHB  Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@noaa.gov
Chris Barker
Sure  but I'm afraid that there will be a lot of code that does an isinstance() check where it it absolutely unnecessary. If you really need to know if something is a sequence or a mapping, I suppose it's required, but how often is that?
I must say I don't understand the purpose of Javalike interfaces in Python. It is better to ask forgiveness than ask permission. If an object does not have the required attributes we sooner or later get an AttributeError. Is doing an isinstance() check and then raising TypeError inherently better? In both cases we get an error that unit tests should detect. I might do sanity checks on the input data if it is required to ensure correct output. But I never do this to ensure that objects have all the attributes they should. If they don't I prefer my program to die with an unhandled AttributeError. Sturla
participants (7)

Alexander Belopolsky

Anthony Scopatz

Chris Barker

Chris Barker  NOAA Federal

Robert Kern

Sebastian Berg

Sturla Molden