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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
