3.7.0 Maximum recursion depth exceeded

[ironiccode]

When comparing numpy.float64 with float using pytest.approx we reach maximum recursion. It works in pytest 3.5.0 and 3.6.0 thou.
Run on Ubuntu 16.04, python 3.5.2, numpy 1.11.3

It seems that changing

return all(a == self for a in actual.flat)

to

return all(self == a for a in actual.flat)

in pytest_api.py file fixes the issue (see the bottom of traceback below).

import pytest
import numpy as np
val = np.float64(1.0)
val_to_cmp = 1.0
val == pytest.approx(val_to_cmp)

RecursionError                            Traceback (most recent call last)
<ipython-input-8-b44e412779ee> in <module>()
----> 1 val == pytest.approx(val_to_cmp)

~/venvs/dl3/lib/python3.5/site-packages/_pytest/python_api.py in __eq__(self, actual)
    212         """
    213         if _is_numpy_array(actual):
--> 214             return all(a == self for a in actual.flat)
    215 
    216         # Short-circuit exact equality.

~/venvs/dl3/lib/python3.5/site-packages/_pytest/python_api.py in <genexpr>(.0)
    212         """
    213         if _is_numpy_array(actual):
--> 214             return all(a == self for a in actual.flat)
    215 
    216         # Short-circuit exact equality.

... last 2 frames repeated, from the frame below ...

~/venvs/dl3/lib/python3.5/site-packages/_pytest/python_api.py in __eq__(self, actual)
    212         """
    213         if _is_numpy_array(actual):
--> 214             return all(a == self for a in actual.flat)
    215 
    216         # Short-circuit exact equality.

RecursionError: maximum recursion depth exceeded while calling a Python object

[nicoddemus]

Thanks for the report @ironiccode.

cc @abrammer @kalekundert @tadeu

[ironiccode]

You're welcome.

I'll try to create a pull request tomorrow.

[tigarmo]

Here's another test that reproduces this issue for me: Fails with max recursion in python 2.7, passes in python 3.6 (haven't checked 3.5):

def testApprox():
    from pytest import approx
    import numpy as np

    a = np.array([1, 2, 3])
    assert a == approx([1, 2, 3])

[abrammer]

well so much for all those tests. @tigarmo What version of numpy are you using? I can't reproduce in 2.7.14 with numpy 1.14.2.

I think the issue would be whether _is_numpy_array() is returning True on the flatiter from ndarray.flat. Though I've only looked at this code for a couple days.

[tigarmo]

Hi @abrammer, it's numpy 1.11.0. Unfortunately our python 2 environment is a bit customized so I'll try to see if I can repro this with a more 'standard' python 2 environment.

[kalekundert]

I had the exact same thought @abrammer. :-) I think you're right that the problem is that _is_numpy_array() is returning true when it shouldn't. It's also weird that switching the order of the operands would do anything. It should end up calling ApproxScalar.__eq__() either way.

[ironiccode]

I've updated info about my numpy version (1.11.3)

[tigarmo]

Good call on the numpy version @abrammer, I confirm that for me the previous test fails with numpy 1.11 but passes with numpy 1.15. Playing with the versions a bit here it seems that the test starts passing in numpy 1.13.0, so here's the changelog for that if anyone is feeling adventurous: https://docs.scipy.org/doc/numpy-1.13.0/release.html

[kalekundert]

My first impression is it has something to do with:

New __array_ufunc__ attribute provides improved ability for classes to override default ufunc behavior.

approx() uses __array_ufunc__ to ensure that its __eq__ operator is called regardless of the order of the operands (otherwise the operand on the left side takes precedence, potentially explaining why putting self on the left solves the problem). I don't understand how the infinite recursion results, though.

[abrammer]

multiple edits later: I think a relevant fix in numpy was here: numpy/numpy#9175

Alright, somehow when this line evaluates the a == self.

pytest/src/_pytest/python_api.py

Line 57 in 2534193

a == self._approx_scalar(x) for a, x in self._yield_comparisons(actual)

It takes the np.int64 or np.float64 of a and changes it to a np.ndarray before it gets to ApproxScalar.__eq__.

_is_numpy_array() correctly returns True, but then recursion starts where the item keeps getting transformed back to an ndarray when the __eq__ is intercepted/evaluated.

flipping the order of __eq__ or explicitly evaluating against ApproxScalar.__eq__ on line 57 solves the problem
¯_(ツ)_/¯

[tigarmo]

@abrammer that is my reading of the issue too. My understanding is that in the numpy versions with the problem, a == self first calls numpy.float64.__eq__ passing self which is an ApproxScalar. Since numpy doesn't know how to handle that it ends up calling ApproxScalar.__eq__ but passes an array with a inside instead of just a. It must be some kind of standardization to arrays that numpy does internally. So then it makes sense that a == self is an infinite recursion.

As you and @ironiccode originally said, flipping the order fixes the problem because it calls ApproxScalar.__eq__ immediatly with the float64 parameter. If it doesn't break anything else I think that's the simplest fix.