Augmented boolean algebra assignments

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.

How is or= different from just or ? See this example for what can be down today.

def test(my_list: None | list):
    for i in (my_list or []):

If my_list is None (or empty) an empty list is used instead.

I think the goal is to be able to write e.g. x or= [], rather than x = x or [], to supply a default value where x is falsey.

1 Like

Yep, that’s it. The augmented assignment version of the operator.

Ah. Got it. Thanks!

Are these different from |= and &= ?

These are the augmented boolean bitwise operators, x &= y is x = x & y and x |= y is x = x | y. They compare by bit, rather than the whole.