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! Be Well Anthony
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. Sturla
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
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
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@gmail.com> 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
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 <sebastian@sipsolutions.net> 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 <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
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 <sebastian@sipsolutions.net> 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 Fri, Feb 28, 2014 at 3:10 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
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, 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
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
On Sat, Mar 1, 2014 at 6:09 PM, Alexander Belopolsky <ndarray@mac.com>wrote:
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
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 passed-in objects? -- probably not! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Chris Barker <chris.barker@noaa.gov> 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
participants (7)
-
Alexander Belopolsky -
Anthony Scopatz -
Chris Barker -
Chris Barker - NOAA Federal
-
Robert Kern -
Sebastian Berg -
Sturla Molden