Message289462
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 :-) |
|
Date |
User |
Action |
Args |
2017-03-12 02:06:36 | tim.peters | set | recipients:
+ tim.peters, vstinner, serhiy.storchaka, ppperry, mdk, elliot.gorokhovsky |
2017-03-12 02:06:35 | tim.peters | set | messageid: <1489284396.0.0.701510194268.issue28685@psf.upfronthosting.co.za> |
2017-03-12 02:06:35 | tim.peters | link | issue28685 messages |
2017-03-12 02:06:34 | tim.peters | create | |
|