Bugs item #980352, was opened at 2004-06-26 17:26 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980352&group_id=5470
Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: coercion results used dangerously Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-12-23 22:14 Message: Logged In: YES user_id=4771 Patch applied. ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 14:15 Message: Logged In: YES user_id=908995 I just filed patch #995939 which should address this. A review would be appreciated. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-26 22:42 Message: 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. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2004-06-26 19:21 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980352&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
