On 29 October 2016 at 07:21, Nick Coghlan <ncogh...@gmail.com> wrote:
> A short-circuiting if-else protocol for arbitrary "THEN if COND else
> ELSE" expressions could then look like this:
>
> _condition = COND
> if _condition:
> _then = THEN
> if hasattr(_condition, "__then__"):
> return _condition.__then__(_then)
> return _then
> else:
> _else = ELSE
> if hasattr(_condition, "__else__"):
> return _condition.__else__(_else)
> return _else
>
> "and" and "or" would then be simplified versions of that, where the
> condition expression was re-used as either the "THEN" subexpression
> ("or") or the "ELSE" subexpression ("and").
>
> The reason I think this is potentially interesting in the context of
> PEPs 505 and 531 is that with that protocol defined, the
> null-coalescing "operator" wouldn't need to be a new operator, it
> could just be a new builtin that defined the appropriate underlying
> control flow:
This seems to have some potential to me. It doesn't seem massively
intrusive (there's a risk that it might be considered a step too far
in "making the language mutable", but otherwise it's just a new
extension protocol around an existing construct). The biggest downside
I see is that it could be seen as simply generalisation for the sake
of it. But with the null-coalescing / sentinel checking use case, plus
Greg's examples from the motivation section of PEP 335, there may well
be enough potential uses to warrant such a change.
Paul
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
