[Python-ideas] PEP 532: A circuit breaking operator and protocol
Sven R. Kunze
srkunze at mail.de
Sat Nov 5 07:59:24 EDT 2016
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
More information about the Python-ideas
mailing list