Issue 980352: coercion results used dangerously (original) (raw)

Created on 2004-06-26 17:26 by arigo, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg21326 - (view)	Author: Armin Rigo (arigo) *	Date: 2004-06-26 17:26
The C core uses the result of PyNumber_CoerceEx() dangerously: it gets passed to tp_compare, and most tp_compare slots assume they get two objects of the same type. This assumption is never checked, even when a user-defined __coerce__() is called: >>> class X(object): ... def __coerce__(self, other): ... return 4, other ... >>> slice(1,2,3) == X() Segmentation fault
msg21327 - (view)	Author: Neil Schemenauer (nascheme) *	Date: 2004-06-26 19:21
Logged In: YES user_id=35752 This bug should obviously get fixed but in long term I think __coerce__ should go away. Do you think deprecating it for 2.4 and then removing support for it in 2.5 or 2.6 is feasible?
msg21328 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2004-06-26 22:42
Logged In: YES user_id=80475 I looked back at one of my ASPN recipes, http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/265894 , and saw that the use of __coerce__ dramatically simplified the code. Also, the API for rich comparisons is not only complex, but it is not entirely sef-consistent. See Tim's "mini-bug" comment in sets.py for an example. IOW, I think it is premature to pull the plug.
msg21329 - (view)	Author: Dima Dorfman (ddorfman)	Date: 2004-07-22 14:15
Logged In: YES user_id=908995 I just filed patch #995939 which should address this. A review would be appreciated.
msg21330 - (view)	Author: Armin Rigo (arigo) *	Date: 2004-12-23 22:14
Logged In: YES user_id=4771 Patch applied.