Tim Peters added the comment: I haven't tried the example, but at this point I'd be surprised if it failed. The caching here isn't at level of `__lt__` but at the higher level of (invisible from Python code) a type's tp_richcompare slot. A heap type - regardless of whether it derives from a C-level or Python-level type - has to be prepared for methods to pop into existence, change, or vanish at (almost) any time. So its tp_richcompare has to be defensive itself. For example:
>>> class F(float): ... pass >>> a = F(2) >>> b = F(3) >>> a < b True Is F.tp_richcompare the same as float.tp_richcompare? We can't tell from Python code, because tp_richcompare isn't exposed. But, _whatever_ F.tp_richcompare is, it notices when relevant new methods are defined (which float.tp_richcompare emphatically does not); for example, continuing the above: >>> F.__lt__ = lambda a, b: 0 >>> a < b 0 >>> del F.__lt__ >>> a < b True That said, I know nothing about how comparison internals changed for Python 3, so I may just be hallucinating :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28685> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
