On Tue, Dec 22, 2020 at 11:44 PM Alan G. Isaac wrote:
> My question is not about work arounds.
> It is about whether the current definition of a sequence
> (in collections.abc) should govern `assertSequenceEqual`.
>
Why do you think a NumPy array is a sequence?
E.g.:
>>> a
array([[1, 2],
This comment completely misses the point.
This "weird type" qualifies as a Sequence.
(See collections.abc.)
Alan Isaac
On 12/22/2020 3:09 PM, Ivan Pozdeev via Python-Dev wrote:
Or just bail out ("resist the temptation to guess") and tell the user to
compare their weird types themselves.
_
On 22/12/2020 19:08, Brett Cannon wrote:
... The fact that numpy chooses to implement __eq__ in such a way that
its result would be surprising if used in an `if` guard I think is
more a design choice/issue of numpy than a suggestion that you can't
trust `==` in testing because it _can_ be som
Numpy chose to violate the principal of equality by having __eq__ not
return a bool. So a numpy type can't be used reliably outside of the numpy
DSL.
-gps
On Tue, Dec 22, 2020, 11:51 AM Alan G. Isaac wrote:
> Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean
> values).
>
On 22.12.2020 22:59, Ivan Pozdeev via Python-Dev wrote:
In the light of this and https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970 (linked
to from https://mail.python.org/archives/list/python-dev@python.org/message/AQRLRVY7EJT4LTOCV7CLOFK
In the light of this and https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970 (linked
to from https://mail.python.org/archives/list/python-dev@python.org/message/AQRLRVY7EJT4LTOCV7CLOFK3FJJTVYYM/ )
I reckon that
*like the other code before it
Okay, I see that by "fails", you probably meant "raises this exception" rather
than fails the usual way (i.e. raises anAssertionError).
On 22.12.2020 22:38, Alan G. Isaac wrote:
Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean
values).
hth, Alan Isaac
On 12/22/2020 2:
Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean
values).
hth, Alan Isaac
On 12/22/2020 2:28 PM, Ivan Pozdeev via Python-Dev wrote:
You sure about that? For me, bool(np.array) raises an exception:
In [12]: np.__version__ Out[12]: '1.19.4'
In [11]: if [False, False]==
On Tue, Dec 22, 2020 at 6:57 PM Alan G. Isaac wrote:
> The following test fails because because `seq1 == seq2` returns a
> (boolean) NumPy array
> whenever either seq is a NumPy array.
>
> import unittest
> import numpy as np
> unittest.TestCase().assertSequenceEqual([1.,2.,3.],
>
On 22.12.2020 21:52, Alan G. Isaac wrote:
The following test fails because because `seq1 == seq2` returns a (boolean)
NumPy array
whenever either seq is a NumPy array.
You sure about that? For me, bool(np.array) raises an exception:
In [12]: np.__version__
Out[12]: '1.19.4'
In [11]: if [Fal
Interesting. Did you look at the code? It is here (that's the `==` operator
you're complaining about):
https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970
The code does already analyze the length of the sequence
You are right that collections
On Tue, Dec 22, 2020 at 10:54 AM Alan G. Isaac wrote:
> The following test fails because because `seq1 == seq2` returns a
> (boolean) NumPy array
> whenever either seq is a NumPy array.
>
> import unittest
> import numpy as np
> unittest.TestCase().assertSequenceEqual([1.,2.,3.],
>
The following test fails because because `seq1 == seq2` returns a (boolean)
NumPy array
whenever either seq is a NumPy array.
import unittest
import numpy as np
unittest.TestCase().assertSequenceEqual([1.,2.,3.], np.array([1.,2.,3.]))
I expected `unittest` to rely only on features o
13 matches
Mail list logo