In article <[EMAIL PROTECTED]>,
Peter Otten <[EMAIL PROTECTED]> wrote:
>Tim Peters wrote:
>
>> See the Python (language, not library) reference manual, section 3.3.8
>> ("Coercion rules"), bullet point starting with:
>>
>> Exception to the previous item: if the left operand is an
>> instanc
Peter Otten wrote:
Tim Peters wrote:
See the Python (language, not library) reference manual, section 3.3.8
("Coercion rules"), bullet point starting with:
Exception to the previous item: if the left operand is an
instance of a built-in type or a new-style class, and the right
operand is
Tim Peters wrote:
> See the Python (language, not library) reference manual, section 3.3.8
> ("Coercion rules"), bullet point starting with:
>
> Exception to the previous item: if the left operand is an
> instance of a built-in type or a new-style class, and the right
> operand is an
[Mel Wilson]
> :) Seems to:
>
>
> Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class Eq(object):
> ... def __eq__(self, other):
> ... return True
> ...
> >>> class Neq(Eq
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
>Mel Wilson wrote:
>> In article <[EMAIL PROTECTED]>,
>> Steven Bethard <[EMAIL PROTECTED]> wrote:
>>
>>>I believe what Peter Otten was pointing out is that calling __eq__ is
>>>not the same as using ==, presumably because th
Steven Bethard wrote:
Mel Wilson wrote:
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
I believe what Peter Otten was pointing out is that calling __eq__ is
not the same as using ==, presumably because the code for == checks the
types of the two objects and returns False
Mel Wilson wrote:
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
I believe what Peter Otten was pointing out is that calling __eq__ is
not the same as using ==, presumably because the code for == checks the
types of the two objects and returns False if they're different b
Mel Wilson wrote:
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
I believe what Peter Otten was pointing out is that calling __eq__ is
not the same as using ==, presumably because the code for == checks the
types of the two objects and returns False if they're different b
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
>I believe what Peter Otten was pointing out is that calling __eq__ is
>not the same as using ==, presumably because the code for == checks the
>types of the two objects and returns False if they're different before
>the __eq
Terry Reedy wrote:
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
>>>def __eq__(self, other):
"""x.__eq__(y) <==> x == y"""
return (isinstance(other, self.__class__)
Since an instance of a subclass is an instance of a parent class, but not
vice versa, I believe you introduce here the
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
>>>def __eq__(self, other):
>>>"""x.__eq__(y) <==> x == y"""
>>>return (isinstance(other, self.__class__)
Since an instance of a subclass is an instance of a parent class, but not
vice versa, I believe you introduce here the assymetr
11 matches
Mail list logo
