Message3188

Author leosoto
Recipients fwierzbicki, leosoto, pjenvey
Date 2008-05-12.16:16:05
SpamBayes Score 0.0032107066
Marked as misclassified No
Message-id <1210608967.21.0.649647587988.issue1031@psf.upfronthosting.co.za>
In-reply-to
Content
OK. Here is the CPython behaviour for cmp(v, w), from
Objects/object.c:do_cmp. Here tp_compare is the C function that
implements three-way comparison, similar to our PyObject#__cmp__. It is
a series of strategies, tried one after the other:

  - if the types are the same, use the tp_compare function of the type
  - use (and adapt) rich comparison if possible (details later)
  - use 3-way comparison if posible (details later)
  - use the "default" 3-way comparison (pointer address if same type,
class name if different types, considering numbers as are always smaller
than objects of other types, and None as the smallest thing ever)

The second attempt there was using rich comparison. PEP 207 have the
details of the adaptation to end with a series of single rich comparison
operation (such as __eq__, __lt__, ...). Each of these single operations
 proceed as the following (from objects.c:try_rich_compare):

  - if the second argument is a subtype of the first, and have
tp_richcompare, call it (swapping the arguments), and use the result
unless it is NotImplemented.
  - if the first argument have tp_richcompare, call it and use the
result, unless it is NotImplemented.
  - if the second argument have tp_richcompare, call it (swapping the
arguments) and use the result, unless it is NotImplemented.
  - return NotImplemented.

Finally, three way comparison (the third trial of the first recipe) acts
as the following (from objects.c:try_3way_compare):

  - use the __cmp__ of the first argument that is an old-style instance
and implements __cmp__.
  - if both tp_compares are the same, use it.
  - use the __cmp__ of the first argument that is a new-style instance
and implements[*] __cmp__.
  - coerce the arguments and, if the coerced types have the same
tp_compare, use it.

Once we already have all this mess in place, it is easy to show how an
externally called rich comparison works. That is, when the comparison
operators (==, !=, <, ...) are used:

 - Try rich comparison, as detailed on the second recipe, and use its
return value unless it is NotImplemented.
 - Use three way comparison, as detailed on the third recipe, and adapt
the result.

That's from objects.c:do_richcmp.

Now I'm going to take a close look at the Jython implementation hoping
to spot what's different there and how these differences can lead to
incompatibilities in practice.
History
Date User Action Args
2008-05-12 16:16:07leosotosetspambayes_score: 0.00321071 -> 0.0032107066
messageid: <1210608967.21.0.649647587988.issue1031@psf.upfronthosting.co.za>
2008-05-12 16:16:07leosotosetspambayes_score: 0.00321071 -> 0.00321071
recipients: + leosoto, fwierzbicki, pjenvey
2008-05-12 16:16:06leosotolinkissue1031 messages
2008-05-12 16:16:05leosotocreate