> On 22 Jul 2024, at 16:35, Paul Howarth <p...@city-fan.org> wrote: > > On Sun, 21 Jul 2024 21:48:55 +0100 > Barry <ba...@barrys-emacs.org> wrote: > >>>> On 21 Jul 2024, at 10:22, Paul Howarth <p...@city-fan.org> wrote: >>> >>> Hence the check is: >>> >>> except UnsupportedAlgorithm as e: >>> return e._reason is _Reasons.UNSUPPORTED_HASH >> >> This may be a case of the e._reason being the correct int value of _ >> Reasons.UNSUPPORTED_HASH by not the singleton. So “is” fails but when >> == coerces to int it is True. >> >> You would need to print out both values to see if this is the case. >> >> I would have coded == in this case. I am curious >> where you read that “is” is recommended? > > In general: > https://docs.python.org/3/howto/enum.html#comparisons
Thanks, interesting reading. > > In this specific case, cryptography's own test suite uses an identity > comparison for the same purpose: > > @contextmanager > def raises_unsupported_algorithm(reason): > with pytest.raises(UnsupportedAlgorithm) as exc_info: > yield exc_info > > assert exc_info.value._reason is reason > > > > Anyway, it seems like this is a Python+Rust problem: > https://github.com/pyca/cryptography/issues/11332 > https://github.com/PyO3/pyo3/issues/3059 I did wonder if it was a rust to python regression. > > So I'll change to '==', which should work even if the underlying issue > is fixed later. Yep, defined in the python enum howto to be supported. Barry > > Regards, Paul. > -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
