This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients elliot.gorokhovsky, mdk, ppperry, serhiy.storchaka, tim.peters, vstinner
Date 2017-03-12.02:06:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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

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
>>> del F.__lt__
>>> a < b

That said, I know nothing about how comparison internals changed for Python 3, so I may just be hallucinating :-)
Date User Action Args
2017-03-12 02:06:36tim.peterssetrecipients: + tim.peters, vstinner, serhiy.storchaka, ppperry, mdk, elliot.gorokhovsky
2017-03-12 02:06:35tim.peterssetmessageid: <>
2017-03-12 02:06:35tim.peterslinkissue28685 messages
2017-03-12 02:06:34tim.peterscreate