You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DocTest sorts by lineno which may be int or None #94722
In doctest.py the following ordering is defined for the class DocTest:
def __lt__(self, other):
if not isinstance(other, DocTest):
return NotImplemented
return ((self.name, self.filename, self.lineno, id(self))
<
(other.name, other.filename, other.lineno, id(other)))
This is incorrect because the lineno field may be an integer and may be None, and comparisons between integers and None fail. Typically lineno is an integer, but _find_lineno explicitly can fall back to returning None so the field may be None:
def _find_lineno(self, obj, source_lines):
...
# We couldn't find the line number.
return None
I'm reporting this because I actually was getting 'int < None not valid' exceptions from this comparison. I would have included a repro but the way i was triggering it was complex enough that it really wasn't worth the time. It involved pybind, installing from sdist not wheel, machine architecture detection, patching in a __test__ dictionary with fake entries to work around properties not being tested, and more! And I wasn't able to get the bug happening consistently outside of one specific dev environment, so even if I'd given the repro I suspected it wouldn't necessarily happen on other machines.
Even if that "names same implies lineno not null" invariant did in fact hold, that invariant is pretty complicated. It would need to be documented. Much easier to just replace self.lineno with self.lineno or -1 in the tuple.
Activity
pochmann commentedon Jul 10, 2022
Can that happen despite equal names and equal filenames?
Strilanc commentedon Jul 10, 2022
I'm reporting this because I actually was getting 'int < None not valid' exceptions from this comparison. I would have included a repro but the way i was triggering it was complex enough that it really wasn't worth the time. It involved pybind, installing from sdist not wheel, machine architecture detection, patching in a
__test__dictionary with fake entries to work around properties not being tested, and more! And I wasn't able to get the bug happening consistently outside of one specific dev environment, so even if I'd given the repro I suspected it wouldn't necessarily happen on other machines.Even if that "names same implies lineno not null" invariant did in fact hold, that invariant is pretty complicated. It would need to be documented. Much easier to just replace
self.linenowithself.lineno or -1in the tuple.pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
gh-94722: fix DocTest.__eq__ for case of no line number on one side (#âĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
[3.11] gh-94722: fix DocTest.__eq__ for case of no line number on oneâĶ
[3.12] gh-94722: fix DocTest.__eq__ for case of no line number on oneâĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ
pythongh-94722: fix DocTest.__eq__ for case of no line number on one âĶ