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.