Repository navigation
exceptions.py tests failing on >= 3.7 because repr changed #1088
Description
Activity
- changed the title
[-]exceptions.py tests failing on > 3.7 because repr changed[/-][+]exceptions.py tests failing on >= 3.7 because repr changed[/+]on Jun 30, 2019 Should we aim for python3.7 compatibility? I think removing the trailing comma is good.
We could test for python version number in the test, but this might not be a good thing to start with. It feels like a rabbit hole.
I don’t think this behaviour is well documented anywhere in the official docs (or that built-in exceptions
repris documented at all, at least I cannot find it easily), so perhaps aiming at exact reproduction of any CPython’s behaviour isn’t necessary?I’d myself restrict the tests to checking some minimal requirements that any sane Python3 (including both CPython 3.6 and CPython 3.7) meet. Eg. that the
reprstring contains the exception type first and then later it contains the message – but disregard punctuation entirely. Or just check that the message is enclosed in parentheses.Since this is a detail that CPython changed from version to version, the client code shouldn’t rely on it anyway.
Or since
reprshould give a proper working Python representation (that would yield an object with the same value when passed toeval()) – perhaps doing a round-trip test: checking whethereval()on therepr(exception)gives the same exception would be a good solution that all good Python implementation should pass?EDIT: that’d need an additional util for testing exception equality, something like this might work:
def exceptions_eq(e1, e2): return type(e1) is type(e2) and e1.args == e2.args assert exceptions_eq(OverflowError('a'), eval(repr(OverflowError('a'))))
Reacted by Windel BouwmanThat sounds fair. Then we can add an additional function:
def round_trip(ex): assert exceptions_eq(ex, eval(repr(ex)))
CPython 3.7 changed exception’s
reprimplementation to get rid of a trailing comma:This makes the test case from
exceptions.pyfail on CPython 3.7 and later.Should we get rid of the tests for repr, or perhaps just test substrings (that
reprstring contains both the type and the message)?