[issue12842] Docs: first parameter of tp_richcompare() always has the correct type

Andrew Svetlov added the comment: Fixed in 71a0743f36db and 06bdd7e8fffd -- nosy: +asvetlov resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3 ___ Python t

[issue12842] Docs: first parameter of tp_richcompare() always has the correct type

Mark Lawrence added the comment: The patch has never been applied. I'm not qualified to state whether or not it is correct. -- nosy: +BreamoreBoy ___ Python tracker ___ ___

[issue12842] Docs: first parameter of tp_richcompare() always has the correct type

Changes by Éric Araujo : -- keywords: +needs review stage: -> patch review versions: -Python 3.1 ___ Python tracker ___ ___ Python-b

[issue12842] Docs: first parameter of tp_richcompare() always has the correct type

New submission from Stefan Krah : I've noticed that assumptions about the operand types in tp_richcompare() are not always consistent. As far as I can see, the first parameter in tp_richcompare() is guaranteed to be of the correct type. But in some places the first parameter's type is still chec