Most operators have augmented assignment equivalents : <<=
, ^=
, -=
, //=
, &=
and so on.
However, several operators have no augmented assignment : ==
and !=
are obvious bad ideas since they are sharing the equal sign with the assignment syntax - same reasoning for <=
and >=
, and for <
and >
since they would just turn into the former.
But the last (I think) three examples, before going to asymmetric operators like in
or exotic “operators” like ()
or []
or .
, are or
, and
and is
.
and=
and or=
would be very useful to normalize true and false values : imagine my function accepts a sequence as a parameter for some behavior, but also accepts False or None to disable that behavior. If I’m iterating through the sequence, I may want to replace that value with a ()
and let it go through the for loop. arg or= ()
would be a simpler (and possibly faster ?) syntax than arg = arg or ()
.
And the same for true values, though the use is slightly less frequent in my experience.
is=
I never needed : turning a variable into True if the value was the same as a compared object…?
Would parsing that [a-z]=
kind of word require a very big change in the parser ?
That wouldn’t require any new addition to the datamodel (no i-dunder) since and
, or
and is
can’t be overloaded. Which would in fact be required for equality and inequality augmented assignments, by the way.