[issue3908] Strange heapq behavior on Python 3.0 when overriding __le__

2008-09-19 Thread Giampaolo Rodola' 

New submission from Giampaolo Rodola' [EMAIL PROTECTED]:

import heapq

class foo:
def __init__(self):
self.timeout = 0
def __le__(self, other):
return self.timeout = other.timeout

heap = []
heapq.heappush(heap, foo())
heapq.heappush(heap, foo())


This code on Python 2.x works without problems, by using Python3.0-RC1
it raises the following exception:


heapq.heappush(heap, foo())
TypeError: unorderable types: foo()  foo()


Note that the previous 3.0 beta didn't have such problem.

--
components: Library (Lib)
messages: 73425
nosy: giampaolo.rodola
severity: normal
status: open
title: Strange heapq behavior on Python 3.0 when overriding __le__
versions: Python 3.0

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3908
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3908] Strange heapq behavior on Python 3.0 when overriding __le__

2008-09-19 Thread Sascha Müller 

Sascha Müller [EMAIL PROTECTED] added the comment:

heapq expects a _lt_ method, and the error doesn't occur when the _le_
method is changed to _lt. According to the SVN log, this was changed due
to consistency with lists.sort().

--
nosy: +einmaliger -giampaolo.rodola

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3908
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3908] Strange heapq behavior on Python 3.0 when overriding __le__

2008-09-19 Thread Sascha Müller 

Changes by Sascha Müller [EMAIL PROTECTED]:


--
nosy: +giampaolo.rodola

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3908
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3908] Strange heapq behavior on Python 3.0 when overriding __le__

2008-09-19 Thread Raymond Hettinger 

Raymond Hettinger [EMAIL PROTECTED] added the comment:

It's supposed to be that way.  In 2.6 we support both to help with 
transition. In 3.0, we've cleaned up and made the APIs consistent. Try to 
get in the habit of defining all six rich comparisons to bulletproof code 
and not rely on undocumented implementation details.

--
assignee:  - rhettinger
nosy: +rhettinger
resolution:  - invalid
status: open - closed

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3908
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com