[IronPython] Rich comparison usage by IronPython's heapq implementation

[Jeff Hardy]

Regardless of what's "correct", we should follow what CPython does
(plus, using only __lt__ and __eq__ makes sense). Can you try this in
2.7 to see if it's still an issue, and open a bug if it is? I doubt
we'll make any more changes to 2.6.

- Jeff

On Mon, Mar 14, 2011 at 6:04 AM, Robert Smallshire
<robert at smallshire.org.uk> wrote:
> Hello,
> I recently ran into some issues with IronPython's heapq implementation
> whereby code that functions correctly on CPython failed with IronPython 2.6.
>  The issue is that the CPython implementation of heapq only calls __le__()
> and __eq__() on the heap elements whereas the IronPython implementation
> calls __le__(), __eq__() *and* __gt__().  Although it seems that IronPython
> is well within specification to do so, there are some statements in the
> Python documentation that only __le__() will be used for sorting.  Of
> course, it's arguable whether 'sorting' applies to heapq and indeed other
> similar algorithms or containers which rely on a defined ordering.
> In any case, this is an avoidable difference between CPython and IronPython
> which tripped me up.  I'm not sure whether the correct fix - if one is
> needed at all - is to IronPython's heapq implementation, to CPythons
> documentation, or to both.
> I wrote a little more about the issue here:
>   <http://www.smallshire.org.uk/sufficientlysmall/2011/03/12/specification-of-rich-comparison-protocol-use-by-the-python-standard-library/>
> Rob
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>