On 2007-01-13, Steven D'Aprano [EMAIL PROTECTED] wrote:
I'm writing a class that implements rich comparisons, and I find myself
writing a lot of very similar code. If the calculation is short and
simple, I do something like this:
class Parrot:
def __eq__(self, other):
return
George Sakkis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Steven D'Aprano wrote:
I'm writing a class that implements rich comparisons, and I find myself
writing a lot of very similar code. If the calculation is short and
simple, I do something like this:
class Parrot:
Paul McGuire [EMAIL PROTECTED] wrote:
In Python, this would look like:
class Parrot:
def __eq__(self, other):
return self is other or self.plumage() == other.plumage()
def __ne__(self, other):
return self is not other and self.plumage() != other.plumage()
def
On Jan 13, 12:52 am, Steven D'Aprano
[EMAIL PROTECTED] wrote:
I'm writing a class that implements rich comparisons, and I find myself
writing a lot of very similar code. If the calculation is short and
simple, I do something like this:
class Parrot:
def __eq__(self, other):
On Sat, 13 Jan 2007 10:04:17 -0600, Paul McGuire wrote:
Just a side note on writing these comparison operators. I remember when
learning Java that this was really the first time I spent so much time
reading about testing-for-identity vs. testing-for-equality. The Java
conventional
On Fri, 12 Jan 2007 23:28:06 -0800, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
class Parrot:
def __eq__(self, other):
return self.plumage() == other.plumage()
def __ne__(self, other):
return self.plumage() != other.plumage()
def __lt__(self,
On 2007-01-13, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Sat, 13 Jan 2007 10:04:17 -0600, Paul McGuire wrote:
[snip]
Surely this is only worth doing if the comparison is expensive?
Testing beats intuition, so let's find out...
class Compare:
def __init__(self, x):
self.x = x
On Sat, 13 Jan 2007 22:05:53 +, Neil Cerutti wrote:
Anyone want to argue that this is a worthwhile optimization? :)
Perhaps. But first test it with ==.
Oh the ignominy! That's what happens when I run code at 6am :(
x = CompareWithIdentity(1); y = CompareWithIdentity(1)
timeit.Timer(x
Steven D'Aprano [EMAIL PROTECTED] escribió en el
mensaje
news:[EMAIL PROTECTED]
On Fri, 12 Jan 2007 23:28:06 -0800, Paul Rubin wrote:
If it's that uniform I think you can just use __cmp__:
Good point -- I had somehow picked up the mistaken idea that __cmp__ was
depreciated in favour of
I'm writing a class that implements rich comparisons, and I find myself
writing a lot of very similar code. If the calculation is short and
simple, I do something like this:
class Parrot:
def __eq__(self, other):
return self.plumage() == other.plumage()
def __ne__(self, other):
Steven D'Aprano [EMAIL PROTECTED] writes:
class Parrot:
def __eq__(self, other):
return self.plumage() == other.plumage()
def __ne__(self, other):
return self.plumage() != other.plumage()
def __lt__(self, other):
return self.plumage() other.plumage()
Steven D'Aprano wrote:
I'm writing a class that implements rich comparisons, and I find myself
writing a lot of very similar code. If the calculation is short and
simple, I do something like this:
class Parrot:
def __eq__(self, other):
return self.plumage() == other.plumage()
12 matches
Mail list logo