[issue3051] heapq change breaking compatibility

Roundup Robot added the comment: New changeset 83e4765ec4cb by Raymond Hettinger in branch '3.2': Issue 3051: make pure python code pass the same tests as the C version. http://hg.python.org/cpython/rev/83e4765ec4cb -- ___ Python tracker

[issue3051] heapq change breaking compatibility

Raymond Hettinger added the comment: Maciek, I added the compatability code to the Python version as requested. Now the tests pass for both versions. There is still work to be done to automatically run both versions against the test suite. -- ___

[issue3051] heapq change breaking compatibility

Roundup Robot added the comment: New changeset 103a2eb61069 by Raymond Hettinger in branch '2.7': Issue 3051: make pure python code pass the same tests as the C version. http://hg.python.org/cpython/rev/103a2eb61069 -- nosy: +python-dev ___ Python tr

[issue3051] heapq change breaking compatibility

Éric Araujo added the comment: The global docs index has one entry for “comparison”, which is http://docs.python.org/dev/reference/expressions#not-in This other page says that “in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators”:

[issue3051] heapq change breaking compatibility

R. David Murray added the comment: For what it's worth, I agree with Fijal. I think the python version and the C version should behave the same, so that other implementations of Python can use the Python version and be compatible wtih CPython. -- nosy: +r.david.murray __

[issue3051] heapq change breaking compatibility

Raymond Hettinger added the comment: Am closing this. It would make no sense to change simple, pure python code to support objects implementing only one of the rich comparison methods. People implementing rich comparisons need to implement all six if they want to guarantee total ordering an

[issue3051] heapq change breaking compatibility

Maciek Fijalkowski added the comment: I cannot honestly make much sense from what you said. My concern is whether python and C version behaves the same or not. It seems that in current version they intentionally behave differently, for simplicity and it's against policy of having the same fun

[issue3051] heapq change breaking compatibility

Raymond Hettinger added the comment: All six of the rich comparisons need to be implemented or the result is undefined. This module never made guarantees for objects defining only one of the six. We could change the pure python code to handle both __lt__ and __le__ but that would make it mu

[issue3051] heapq change breaking compatibility

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue3051] heapq change breaking compatibility

Changes by Jean-Paul Calderone : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue3051] heapq change breaking compatibility

Maciek Fijalkowski added the comment: Hello. I would like to complain. It was decided at some point some time ago that both pure-python and C version should run against the same test suite and should not have any differencies. The reasoning behind it is that other python implementations migh

[issue3051] heapq change breaking compatibility

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: There should be no cases where the pure python code runs instead of the C code. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3051] heapq change breaking compatibility

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Thanks for the explanation. Unfortunately, even if we change our code to work with the new requirements, all the old code is still out there. Maybe this doesn't matter, since there are so many other incompatibilities between Python 2.5

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: I saw no need to complicate the pure python code for this. Really, the client code should use __cmp__ or define all six rich comparisons. ___ Python tracker <[EMAIL PROTECTED]>

[issue3051] heapq change breaking compatibility

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: I tried this too and then wrote a couple unit tests for this. The one for the Python implementation which tests the case where only __le__ is defined fails, though. Diff attached. -- keywords: +patch Added file: http://bugs.pyt

[issue3051] heapq change breaking compatibility

Thomas Herve <[EMAIL PROTECTED]> added the comment: Sure, that's fine with me. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list ma

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Would like to make the 3.0 code use __lt__ only. Any objections? -- priority: high -> normal ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3051] heapq change breaking compatibility

Thomas Herve <[EMAIL PROTECTED]> added the comment: Yes, the last commit did the trick. Thanks. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Py

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Thomas, please let me know if r64116 works for you. ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3051] heapq change breaking compatibility

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- status: closed -> open ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue3051] heapq change breaking compatibility

Thomas Herve <[EMAIL PROTECTED]> added the comment: Unfortunately, the modification didn't fix the problem. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Fixed in r63998. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: I'll fix this to accommodate both cases, __lt__ and __le__. After trying xx with x=x with x<=y, and may swap the arguments of x==y and x!=y." -- PEP 207 -- priority: -> high ___ Python tracke

[issue3051] heapq change breaking compatibility

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: The heapq documentation isn't very clear about its requirements. It does explicitly say that "Heaps are arrays for which heap[k] <= heap[2*k+1] and heap[k] <= heap[2*k+2] for all k, counting elements from zero." (this in the module refer

[issue3051] heapq change breaking compatibility

Thomas Herve <[EMAIL PROTECTED]> added the comment: Okay then. At least the issue is recorded somewhere, if someone has the same problem. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3051] heapq change breaking compatibility

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: It would be better if the Twisted code changed to define all of the rich comparisons instead of relying on an accidental and erroneous implementation detail. The heapq change because other people's code that used __lt__ was breaking. T

[issue3051] heapq change breaking compatibility

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3051] heapq change breaking compatibility

New submission from Thomas Herve <[EMAIL PROTECTED]>: A recent change in heapq implements it in terms of less-than: http://svn.python.org/view/python/trunk/Modules/_heapqmodule.c?rev=63827&r1=63675&r2=63827 Unfortunately, it breaks usage of heapq when a class only implements __le__ and not __ge_