On Fr, 2014-02-28 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.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

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 wrote:

...

On Fr, 2014-02-28 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.dev-eb40f65'

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 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 Fr, 2014-02-28 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.dev-eb40f65'

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 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

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 wrote: On Fri, Feb 28, 2014 at 9:03 AM, Sebastian Berg wrote: > On Fr, 2014-02-28 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.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 wrote: > On Fr, 2014-02-28 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.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

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/pep-3119/#abcs-vs-duck-typing

Chris Barker wrote:

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 Java-like 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