Re: Constraints on __sub__, __eq__, etc.
Benjamin Kaplan
> It seems intuitive to me that the magic methods for overriding the +, -, <,
> ==, >, etc. operators should have no sideffects on their operands. Also,
> that == should be commutative and transitive, that > and < should be
> transitive, and anti-commutative.
> Is this intuition written up in a PEP, or assumed to follow from the
> mathematical meanings?
> - Andrey
There are no assumptions about anything. You can do whatever you want
when you implement the functions yourself. For the numeric types, they
follow the intuitive meanings but that's not necessary for user
defined types. Of course, your users will get very confused if a == b
but b != a. Or if a == b and a != b at the same time.
Robert Kern
> It seems intuitive to me that the magic methods for overriding the +, -,
> <, ==, >, etc. operators should have no sideffects on their operands.
> Also, that == should be commutative and transitive, that > and < should
> be transitive, and anti-commutative.
>
> Is this intuition written up in a PEP, or assumed to follow from the
> mathematical meanings?
Some of it is covered in the reference manual. E.g.
http://docs.python.org/reference/datamodel.html#object.__lt__
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Jean-Michel Pichavant
>
> It may be intuitive to you, but its not true, written down
> anywhere, nor assumed by the language, and the mathematical
> meaning of the operators doesn't matter to Python. Python
> purposefully does not enforce anything for these methods.
>
>
> Right, so neither is anything in PEP-8, but it's still considered
> "good practice". I'm running across examples like you gave (__sub__
> having a side-effect on the left-hand operand) in some code, and am
> trying to find concrete justification for avoiding it.
>
> - Andrey
This is all about communication. Python allows you to call a cat a dog.
You'll confuse everyone if you do so, but you can do it.
If your '-' operator is doing something else than returning the sub
result, it's your call, but do not expect people to get it easily. You'd
better be good at writting the documentation :-)
JM
Roald de Vries
> On Thu, Feb 18, 2010 at 8:19 AM, Andrey Fedorov
> <anfe...@gmail.com>wrote:
>> It seems intuitive to me that the magic methods for overriding the
>> +, -, <, ==, >, etc. operators should have no sideffects on their
>> operands. Also, that == should be commutative and transitive, that
>> > and < should be transitive, and anti-commutative.
>>
>> Is this intuition written up in a PEP, or assumed to follow from
>> the mathematical meanings?
>
> nor assumed by the language, and the mathematical meaning of the
> operators doesn't matter to Python. Python purposefully does not
> enforce anything for these methods.
Still, it's clear that (for example) '==' is not just a normal
function call. Look at this example (in ipython):
>>> False == False == False
True
>>> True == False == False
False
>>> (True == False) == False
True
Anybody knows how why this is so?
Chris Rebert
Python is smart enough to recognize chained comparisons and do The
Right Thing (tm).
`X == Y == Z` is equivalent to `X == Y and Y == Z`. Same goes for the
other comparison operators besides == and also possibly for longer
chains.
Cheers,
Chris
--
http://blog.rebertia.com
Peter Otten
As Chris said
expr1 <op1> expr2 <op2> expr3 <op3> ...
is resolved as
(expr1 <op1> expr2) and (expr2 <op2> expr3) and (expr3 <op3> ...
where each exprN is evaluated just once.
For this to become the obvious way you have to look at interval checks like
a < b < c
Peter