Hello group,
I'm porting some code of mine to Python 3. One class has the __cmp__
operator overloaded, but comparison doesn't seem to work anymore with that:
Traceback (most recent call last):
File "./parse", line 25, in <module>
print(x < y)
TypeError: unorderable types: IP() < IP()
Was there some kind of semantic change?
Kind regards,
Johannes
--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48**********************@news.sunrise.ch>
17  2683 
On Nov 20, 1:18*pm, Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
Hello group,
I'm porting some code of mine to Python 3. One class has the __cmp__
operator overloaded, but comparison doesn't seem to work anymore with that:
Traceback (most recent call last):
* File "./parse", line 25, in <module>
* * print(x < y)
TypeError: unorderable types: IP() < IP()
Was there some kind of semantic change?
Overload __lt__ method.
Inyeol In********@gmail.com schrieb:
On Nov 20, 1:18 pm, Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
>Hello group,
I'm porting some code of mine to Python 3. One class has the __cmp__
operator overloaded, but comparison doesn't seem to work anymore with that:
Traceback (most recent call last):
File "./parse", line 25, in <module>
print(x < y)
TypeError: unorderable types: IP() < IP()
Was there some kind of semantic change?
Overload __lt__ method.
Well, of course I could do that, but the python doc says:
"Called by comparison operations if rich comparison (see above) is not
defined." http://www.python.org/doc/2.5.2/ref/customization.html
And my code works just fine with 2.5 - only on 3.0 it doesn't work
anymore. Why is that?
Regards,
Johannes
--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48**********************@news.sunrise.ch>
Johannes Bauer wrote:
Hello group,
I'm porting some code of mine to Python 3. One class has the __cmp__
operator overloaded, but comparison doesn't seem to work anymore with that:
__cmp__ is gone
Christian
Johannes Bauer wrote:
In********@gmail.com schrieb:
>On Nov 20, 1:18 pm, Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
>>Hello group,
I'm porting some code of mine to Python 3. One class has the __cmp__
operator overloaded, but comparison doesn't seem to work anymore with that:
Traceback (most recent call last):
File "./parse", line 25, in <module>
print(x < y)
TypeError: unorderable types: IP() < IP()
Was there some kind of semantic change?
Overload __lt__ method.
Well, of course I could do that, but the python doc says:
"Called by comparison operations if rich comparison (see above) is not
defined."
http://www.python.org/doc/2.5.2/ref/customization.html
And my code works just fine with 2.5 - only on 3.0 it doesn't work
anymore. Why is that?
Well the Python 2.5 documentation can't be regarded as a reliable guide
to what to expect in 3.0 ...
You will observe that __cmp__ no longer appears in the index: http://docs.python.org/dev/3.0/genindex-_.html
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steve Holden <st***@holdenweb.comwrites:
You will observe that __cmp__ no longer appears in the index:
http://docs.python.org/dev/3.0/genindex-_.html
I searched in vain for an official description of this changed
behaviour. Where can we find an official description of how
comparisons are different in Python 3.0?
--
\ “[Entrenched media corporations will] maintain the status quo, |
`\ or die trying. Either is better than actually WORKING for a |
_o__) living.†—ringsnake.livejournal.com, 2007-11-12 |
Ben Finney
Ben Finney wrote:
Steve Holden <st***@holdenweb.comwrites:
>You will observe that __cmp__ no longer appears in the index:
http://docs.python.org/dev/3.0/genindex-_.html
I searched in vain for an official description of this changed
behaviour. Where can we find an official description of how
comparisons are different in Python 3.0?
If it's not present then it would be worth reporting it as a 3.0 bug -
there's still time to get it in, as the release isn't due until early
December.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Ben Finney wrote:
Steve Holden <st***@holdenweb.comwrites:
>You will observe that __cmp__ no longer appears in the index:
http://docs.python.org/dev/3.0/genindex-_.html
I searched in vain for an official description of this changed
behaviour. Where can we find an official description of how
comparisons are different in Python 3.0?
I was going to say "look in "What's New", but the __cmp__ removal is
missing. So I filed http://bugs.python.org/issue4372
Steve Holden schrieb:
If it's not present then it would be worth reporting it as a 3.0 bug -
there's still time to get it in, as the release isn't due until early
December.
Seems it was removed on purpose - I'm sure there was a good reason for
that, but may I ask why? Instead of the sleek __cmp__ function I had
earlier, I now have code like:
def __lt__(self, other):
return self.__cmp__(other) < 0
def __le__(self, other):
return self.__cmp__(other) < 0
def __gt__(self, other):
return self.__cmp__(other) 0
def __ge__(self, other):
return self.__cmp__(other) >= 0
Does anyone know the reason why __cmp__ was discarded?
Kind regards,
Johannes
--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48**********************@news.sunrise.ch>
Christian Heimes wrote:
Terry Reedy wrote:
>I was going to say "look in "What's New", but the __cmp__ removal is
missing. So I filed
http://bugs.python.org/issue4372
The whatsnew section of Python 3.0 is still empty. Guido didn't had time
to write it. http://bugs.python.org/issue2306
What's New in Python 3.0 is incomplete but definitely not empty, and it
is part of the doc set.
Johannes Bauer wrote:
Steve Holden schrieb:
>If it's not present then it would be worth reporting it as a 3.0 bug -
there's still time to get it in, as the release isn't due until early
December.
Seems it was removed on purpose - I'm sure there was a good reason for
that, but may I ask why? Instead of the sleek __cmp__ function I had
earlier, I now have code like:
def __lt__(self, other):
return self.__cmp__(other) < 0
def __le__(self, other):
return self.__cmp__(other) < 0
def __gt__(self, other):
return self.__cmp__(other) 0
def __ge__(self, other):
return self.__cmp__(other) >= 0
Does anyone know the reason why __cmp__ was discarded?
See previous threads, including recent one about sorting.
Johannes Bauer <df***********@gmx.dewrote:
Seems it was removed on purpose - I'm sure there was a good reason for
that, but may I ask why? Instead of the sleek __cmp__ function I had
earlier, I now have code like:
def __lt__(self, other):
return self.__cmp__(other) < 0
def __le__(self, other):
return self.__cmp__(other) < 0
I hope you actually have <= here.
>
def __gt__(self, other):
return self.__cmp__(other) 0
def __ge__(self, other):
return self.__cmp__(other) >= 0
Does anyone know the reason why __cmp__ was discarded?
I think it was because __cmp__ was the backward compatible fallback for
the newer rich comparison methods and Python 3 cleans up a lot of stuff
left in just for backward compatibility. In this case it is a cleanup
too far as in most cases (i.e. those cases where you don't need the full
complexity of the rich comparisons) __cmp__ is a much simpler solution.
See http://mail.python.org/pipermail/pyt...ch/034073.html
for Guido's original thoughts. Also, once upon a time pep-3000 referred
to the removal of __cmp__ but I can't find it in any of the current
peps. See http://mail.python.org/pipermail/pyt...st/042959.html
and http://mail.python.org/pipermail/pyt...st/042972.html
where the reference to removal of __cmp__ became "Comparisons other than
``==`` and ``!=`` between disparate types will raise an exception unless
explicitly supported by the type" and the reference to Guido's email
about removing __cmp__ was also removed.
--
Duncan Booth http://kupuguy.blogspot.com
On Nov 21, 4:09*am, Duncan Booth <duncan.bo...@invalid.invalidwrote:
Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
Seems it was removed on purpose - I'm sure there was a good reason for
that, but may I ask why? Instead of the sleek __cmp__ function I had
earlier, I now have code like:
def __lt__(self, other):
* * *return self.__cmp__(other) < 0
def __le__(self, other):
* * *return self.__cmp__(other) < 0
I hope you actually have <= here.
def __gt__(self, other):
* * *return self.__cmp__(other) 0
def __ge__(self, other):
* * *return self.__cmp__(other) >= 0
Does anyone know the reason why __cmp__ was discarded?
I think it was because __cmp__ was the backward compatible fallback for
the newer rich comparison methods and Python 3 cleans up a lot of stuff
left in just for backward compatibility. In this case it is a cleanup
too far as in most cases (i.e. those cases where you don't need the full
complexity of the rich comparisons) __cmp__ is a much simpler solution.
Seehttp://mail.python.org/pipermail/python-dev/2003-March/034073.html
for Guido's original thoughts. Also, once upon a time pep-3000 referred
to the removal of __cmp__ but I can't find it in any of the current
peps. Seehttp://mail.python.org/pipermail/python-checkins/2004-August/042959.html
andhttp://mail.python.org/pipermail/python-checkins/2004-August/042972.html
where the reference to removal of __cmp__ became "Comparisons other than
``==`` and ``!=`` between disparate types will raise an exception unless
explicitly supported by the type" and the reference to Guido's email
about removing __cmp__ was also removed.
Guido's primary argument for removing it seems to be that the code for
supporting both __cmp__ and the rich comparisons is "hairy" and that
it felt really satisfying to remove. I don't think that's a good
enough argument. It was hairy because there are a lot of cases to
check, but I wouldn't say it was crufty. It made sense, and the way
it worked seemed logical enough. I never ran into any problems with
it. And by and far the most common case is to implement some total
ordering for a class.
Now, as has been pointed out, all you really need to define total
ordering, at least for sorting, is __eq__ and __lt__, which isn't too
bad. But you still lose the ability to make any other sort of
comparison without implementing all the other comparison operators
too.
Perhaps the code could be made somewhat simpler like this: If rich
comparisons are defined, use those and *only* those operators that are
defined, and don't try to fall back on __cmp__ otherwise. If no rich
comparisons are defined, just look for __cmp__.
Hyuga <hy**********@gmail.comwrites:
On Nov 21, 4:09*am, Duncan Booth <duncan.bo...@invalid.invalidwrote:
>Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
Seems it was removed on purpose - I'm sure there was a good reason for
that, but may I ask why? Instead of the sleek __cmp__ function I had
earlier, I now have code like:
def __lt__(self, other):
* * *return self.__cmp__(other) < 0
def __le__(self, other):
* * *return self.__cmp__(other) < 0
I hope you actually have <= here.
def __gt__(self, other):
* * *return self.__cmp__(other) 0
def __ge__(self, other):
* * *return self.__cmp__(other) >= 0
Does anyone know the reason why __cmp__ was discarded?
I think it was because __cmp__ was the backward compatible fallback for
the newer rich comparison methods and Python 3 cleans up a lot of stuff
left in just for backward compatibility. In this case it is a cleanup
too far as in most cases (i.e. those cases where you don't need the full
complexity of the rich comparisons) __cmp__ is a much simpler solution.
Seehttp://mail.python.org/pipermail/python-dev/2003-March/034073.html
for Guido's original thoughts. Also, once upon a time pep-3000
referred to the removal of __cmp__ but I can't find it in any of the
current peps. See
http://mail.python.org/pipermail/pyt...st/042959.html
and
http://mail.python.org/pipermail/pyt...st/042972.html
where the reference to removal of __cmp__ became "Comparisons other
than ``==`` and ``!=`` between disparate types will raise an
exception unless explicitly supported by the type" and the reference
to Guido's email about removing __cmp__ was also removed.
Guido's primary argument for removing it seems to be that the code for
supporting both __cmp__ and the rich comparisons is "hairy" and that
it felt really satisfying to remove. I don't think that's a good
enough argument. It was hairy because there are a lot of cases to
check, but I wouldn't say it was crufty. It made sense, and the way
it worked seemed logical enough. I never ran into any problems with
it. And by and far the most common case is to implement some total
ordering for a class.
Now, as has been pointed out, all you really need to define total
ordering, at least for sorting, is __eq__ and __lt__, which isn't too
bad. But you still lose the ability to make any other sort of
comparison without implementing all the other comparison operators
too.
As classes can be decorated in Python 3, you can write a decorator to
make a class totally ordered. Here is a very simplified proof of
concept such decorator:
def totally_ordered(cls):
if not hasattr(cls, '__gt__'):
def gt(self, other):
return self != other and not self < other
cls.__gt__ = gt
# Do the same with __le__, __ge__
return cls
@totally_ordered
class Fraction:
def __init__(self, num, den=1):
assert den 0, "denomintator must be 0"
self.num = num
self.den = den
def __eq__(self, other):
return self.num*other.den == self.den*other.num
def __lt__(self, other):
return self.num*other.den < self.den*other.num
>>q12=Fraction(1, 2)
q23=Fraction(2, 3)
q12 < q23
True
>>q12 q23
False
Granted it's not as efficient as a __cmp__ function.
--
Arnaud
On Fri, 21 Nov 2008 17:26:21 +0000, Arnaud Delobelle wrote:
[...]
As classes can be decorated in Python 3, you can write a decorator to
make a class totally ordered. Here is a very simplified proof of
concept such decorator:
def totally_ordered(cls):
if not hasattr(cls, '__gt__'):
def gt(self, other):
return self != other and not self < other
cls.__gt__ = gt
# Do the same with __le__, __ge__
return cls
@totally_ordered
class Fraction:
def __init__(self, num, den=1):
assert den 0, "denomintator must be 0" self.num = num
self.den = den
def __eq__(self, other):
return self.num*other.den == self.den*other.num
def __lt__(self, other):
return self.num*other.den < self.den*other.num
>>>q12=Fraction(1, 2)
q23=Fraction(2, 3)
q12 < q23
True
>>>q12 q23
False
Granted it's not as efficient as a __cmp__ function.
What makes you say that? What do you mean by "efficient"? Are you talking
about memory footprint, runtime speed, disk-space, programmer efficiency,
algorithmic complexity, or something else?
As I see it, a __cmp__ method would be written something like this:
def __cmp__(self, other):
return cmp(self.num*other.den, self.den*other.num)
which presumably would save you a trivial amount of source code (and
hence memory footprint, disk-space and programmer efficiency), but the
algorithmic complexity is identical and the runtime speed might even be
trivially slower due to the extra function call.
If your major concern is to reduce the amount of repeated code in the
methods, then there's no reason why you can't write a __cmp__ method as
above and then call it from your rich comparisons:
def __eq__(self, other):
return self.__cmp__(other) == 0
def __lt__(self, other):
return self.__cmp__(other) < 0
and if you really want to be concise:
__gt__ = lambda s, o: s.__cmp__(o) 0
__ge__ = lambda s, o: s.__cmp__(o) >= 0
__le__ = lambda s, o: s.__cmp__(o) <= 0
--
Steven This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: mike420 |
last post by:
I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro...
|
by: Jacob Page |
last post by:
I have created what I think may be a useful Python module, but I'd like
to share it with the Python community to get feedback, i.e. if it's
Pythonic. If it's considered useful by Pythonistas, I'll...
|
by: alainpoint |
last post by:
Hello,
I came accross what i think is a serious bug in the python interpreter.
Membership testing seems not to work for list of objects when these
objects have a user-defined __cmp__ method....
|
by: Antoon Pardon |
last post by:
I was wondering how people would feel if the cmp function and
the __cmp__ method would be a bit more generalised.
The problem now is that the cmp protocol has no way to
indicate two objects are...
|
by: Ben Finney |
last post by:
Howdy all,
PEP 354: Enumerations in Python has been accepted as a draft PEP. The
current version can be viewed online:
<URL:http://www.python.org/peps/pep-0354.html>
Here is the...
|
by: Roman Susi |
last post by:
Hi!
Out of curiosity, how do I draw functions outside classes with UML? How
module could be drawn in this case?
More theoretical question is if I create classes on the fly, how UML can...
|
by: mystilleef |
last post by:
Hello,
What is the Pythonic way of implementing getters and setters. I've
heard
people say the use of accessors is not Pythonic. But why? And what is
the alternative? I refrain from using them...
|
by: Jordan |
last post by:
Hi everyone,
I'm a big Python fan who used to be involved semi regularly in
comp.lang.python (lots of lurking, occasional posting) but kind of
trailed off a bit. I just wrote a frustration...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
