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 <rob...@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@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
