MAINT: Bump hypothesis from 6.10.0 to 6.10.1

[dependabot]

Bumps hypothesis from 6.10.0 to 6.10.1.

Release notes

Sourced from hypothesis's releases.

Hypothesis for Python - version 6.10.1

This patch fixes a deprecation warning if you're using recent versions of importlib-metadata (issue #2934), which we use to load third-party plugins such as Pydantic's integration. On older versions of importlib-metadata, there is no change and you don't need to upgrade.

The canonical version of these notes (with links) is on readthedocs.

Commits

• 883ab7f Bump hypothesis-python version to 6.10.1 and update changelog
• 47cb14e Merge pull request #2947 from Zac-HD/new-importlib
• 9181052 Merge pull request #2948 from HypothesisWorks/create-pull-request/patch
• 596b1be Update pinned dependencies
• ffc161b Use new importlib API
• f94f480 Merge pull request #2941 from HypothesisWorks/create-pull-request/patch
• 46eae04 Update pinned dependencies
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

[charris]

@mattip Do you know if the PyPy failure is new? Or has this revealed a new problem.

[mattip]

I have not seen that before. It does not seem to be related to hypothesis. An underflow warning is turned into an exception that triggers a DeprecationWarning. Since "underflow encountered in equal" does not make sense, I think it is something about a change in the order of operations causing an underflow flag not to be cleared from a previous operation.

relevant part of the log

________ TestUfuncGenericLoops.test_unary_PyUFunc_O_O_method_full[sqrt] ________
FloatingPointError: underflow encountered in equal

The above exception was the direct cause of the following exception:

self = <numpy.core.tests.test_ufunc.TestUfuncGenericLoops object at 0x00007f62ad8dc988>
ufunc = <ufunc 'sqrt'>

    @pytest.mark.parametrize("ufunc", UNARY_OBJECT_UFUNCS)
    def test_unary_PyUFunc_O_O_method_full(self, ufunc):
        """Compare the result of the object loop with non-object one"""
        val = np.float64(np.pi/4)
    
        class MyFloat(np.float64):
            def __getattr__(self, attr):
                try:
                    return super().__getattr__(attr)
                except AttributeError:
                    return lambda: getattr(np.core.umath, attr)(val)
    
        num_arr = np.array([val], dtype=np.float64)
        obj_arr = np.array([MyFloat(val)], dtype="O")
    
        with np.errstate(all="raise"):
            try:
                res_num = ufunc(num_arr)
            except Exception as exc:
                with assert_raises(type(exc)):
                    ufunc(obj_arr)
            else:
                res_obj = ufunc(obj_arr)
>               assert_array_equal(res_num.astype("O"), res_obj)
E               DeprecationWarning: elementwise comparison failed; this will raise an error in the future.

MyFloat    = <class 'numpy.core.tests.test_ufunc.TestUfuncGenericLoops.test_unary_PyUFunc_O_O_method_full.<locals>.MyFloat'>
num_arr    = array([0.78539816])
obj_arr    = array([0.7853981633974483], dtype=object)
res_num    = array([0.88622693])
res_obj    = array([0.8862269254527579], dtype=object)

[seberg]

The flags should be cleared before all ufuncs (whether or not that makes sense) currently. But, if the object loop internally causes the flag to be set (but not cleared), that might then trigger it on finalizing the ufunc.

One thing where this happens in NumPy currently is invalid float casts, but that doesn't really fit. Maybe it can also happen in some scalar math, but I am not sure where.
It seems strange, but if this was specific to PyPy, is there a chance PyPy accidentally does an invalid operation here?

[charris]

I think it is something about a change in the order of operations

Are we randomizing the order the tests are run in these days?

[seberg]

Ah, you restarted, hopefully its just a fluke. I don't think it should be random (unless there is a pytest plugin installed that does it and there was not)... But maybe it is random anyway for some other (possibly PyPy) reason.

Unfortunately assert_array_equal is a fairly complex function, it might make sense to disable the traceback-hide there. I am wondering if the sqrt result can differ for 0-D vs. 1-D (both length 1) input – (EDIT:) the only difference I can think of is that one might use a 0-stride and the other a contiguous one, if that matters for SIMD. If that could happen, the result might actually differ and go into weirder assert_array_compare branches. But that is all fairly random stabs for now.