Thomas Herve added the comment:
Thanks a lot!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
__
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
To be honest, I have no idea what pybots is, and how it's affected.
Maybe you can get someone else interested in reviewing the code? I'm
focusing mostly on Py3k.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
Guido van Rossum added the comment:
Committed revision 59576.
I found some time.
Happy pybotting!
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
__
Changes by Guido van Rossum:
--
keywords: +patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum:
--
priority: high - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
__
___
Python-bugs-list mailing list
Unsubscribe:
Thomas Herve added the comment:
I gave it a try. The following patch corrects 2 problems:
* classes with only __lt__ and __gt__ defined are hashable
* classes defining __eq__ get a meaningful exception.
I've restricted the hash_name_op to the bare minimum, but no tests
failed, so I supposed
New submission from Thomas Herve:
A new behavior was introduced in r59106 in python trunk, which look
suspicious to me. Basically, every time a class defines a comparison
operator, it's __hash__ method is defined to None. The simple following
example shows it:
class A(object):
... def
Thomas Herve added the comment:
Of course, I meant unusable.
--
nosy: +exarkun
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
__
___
Python-bugs-list mailing list
Thomas Herve added the comment:
Also, to be more clear, that happens when you define any of the
functions in the name_op array (__lt__, __le___, __gt__, __ge__, ...).
It's not just a problem about the object being non hashable.
__
Tracker [EMAIL PROTECTED]
Changes by Christian Heimes:
--
assignee: - gvanrossum
nosy: +gvanrossum
priority: - high
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1549
__
___
Python-bugs-list
Jean-Paul Calderone added the comment:
zope.interface.interface.InterfaceClass implements __lt__ and __gt__.
It doesn't override any of the other comparison methods, and it relies
on inheriting an identity-based __hash__ from its parent.
Disabling __hash__ when __cmp__ or __eq__ is defined
Guido van Rossum added the comment:
You have a point. Can you suggest a patch that fixes this?
Question though -- what semantics are used for __lt__ and __gt__ that
they don't require overriding __eq__?
__
Tracker [EMAIL PROTECTED]
Jean-Paul Calderone added the comment:
It implements ordering based on the interface's fully-qualified Python
name (ie, (__module__, __name__)). This is compatible with the default
__eq__ implementation.
__
Tracker [EMAIL PROTECTED]
Guido van Rossum added the comment:
Fair enough.
Still, this would go much faster if someone other than myself could be
coerced into researching how to fix this (at least the Zope use -- I
haven't heard back from the OP).
__
Tracker [EMAIL PROTECTED]
Thomas Herve added the comment:
There are different ways to fix this. Reverting r59016 is one of them,
but I guess it's not an acceptable solution :).
From what I understand of the changes, removing the operations (__lt__,
__gt__, __le__, __ge__) from the name_op array would fix this. But I
Guido van Rossum added the comment:
Well, the name_op array is used for other purposes. Perhaps the main
issue is that the presence of any of these causes the rich comparison
functionality to be overridden. But please do look into this if you can!
__
Tracker
16 matches
Mail list logo
