[ python-Bugs-980352 ] coercion results used dangerously

[SourceForge.net]

Bugs item #980352, was opened at 2004-06-26 12:26
Message generated for change (Comment added) made by rhettinger
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: Open
Resolution: None
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: Raymond Hettinger (rhettinger)
Date: 2004-06-26 17: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 14: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