[Python-ideas] PEP 532: A circuit breaking operator and protocol

[Sven R. Kunze]

Thanks, Nick. This PEP is far easier to read than the previous one.

On 05.11.2016 10:50, Nick Coghlan wrote:
> This PEP has been designed specifically to address the risks and concerns
> raised when discussing PEPs 335, 505 and 531.
>
> * it defines a new operator and adjusts the definition of chained comparison
>    rather than impacting the existing ``and`` and ``or`` operators
> * the changes to the ``not`` unary operator are defined in such a way that
>    control flow optimisations based on the existing semantics remain valid
> * rather than the cryptic ``??``, it uses ``else`` as the operator keyword in
>    exactly the same sense as it is already used in conditional expressions

The "else" keyword I proposed more than a year ago finally lands in a 
PEP. So, I am +1 on this. ;-)

> * it defines a general purpose short-circuiting binary operator that can even
>    be used to express the existing semantics of ``and`` and ``or`` rather than
>    focusing solely and inflexibly on existence checking

This is why I like this PEP most.

> * it names the proposed builtins in such a way that they provide a strong
>    mnemonic hint as to when the expression containing them will short-circuit
>    and skip evaluating the right operand

If you are referring to "missing" and to "exists", I tend to dislike 
them as production code use those very, very often. I think that the 
mnemonic hint comes from the "else" keyword, not from the proposed 
builtins. Furthermore, I still don't find "missing(expr1) else 
expr1.field" very intuitive to read.


Regarding the ?. and ?[] syntactic sugar definitions, they seem very 
well explained. Unfortunately, having a look at our production code 
(configs etc.) specifically, it wouldn't help so much as we usually 
check for attribute existence not obj existence. So, ?. and ?[] define 
in the proposed form might help 50% of the use-cases but would 
disappoint those other 50%.

Cheers,
Sven