[Python-ideas] Inline assignments using "given" clauses

[Guido van Rossum]

Thanks! Perhaps the most useful bit of this post is the clear list of use
cases (a useful summary of the motivational part of PEP 572).

On Fri, May 4, 2018 at 5:06 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> (Note: Guido's already told me off-list that he doesn't like the way this
> spelling reads, but I wanted to share it anyway since it addresses one of
> the recurring requests in the PEP 572 discussions for a more targeted
> proposal that focused specifically on the use cases that folks had agreed
> were reasonable potential use cases for inline assignment expressions.
>
> I'll also note that another potential concern with this specific proposal
> is that even though "given" wasn't used as a term in any easily discovered
> Python APIs back when I first wrote PEP 3150, it's now part of the
> Hypothesis testing API, so adopting it as a keyword now would be markedly
> more disruptive than it might have been historically)
>
> Recapping the use cases where the inline assignment capability received
> the most agreement regarding being potentially more readable than the
> status quo:
>
> 1. Making an "exactly one branch is executed" construct clearer than is
> the case for nested if statements:
>
>     if m := pattern.search(data):
>         ...
>     elif m := other_pattern.search(data):
>         ...
>     else:
>         ...
>
> 2. Replacing a loop-and-a-half construct:
>
>     while m := pattern.search(remaining_data):
>         ...
>
> 3. Sharing values between filtering clauses and result expressions in
> comprehensions:
>
>     result = [(x, y, x/y) for x in data if (y := f(x))]
>
> The essence of the given clause concept would be to modify *these specific
> cases* (at least initially) to allow the condition expression to be
> followed by an inline assignment, of the form "given TARGET = EXPR". (Note:
> being able to implement such a syntactic constraint is a general
> consequence of using a ternary notation rather than a binary one, since it
> allows the construct to start with an arbitrary expression, without
> requiring that expression to be both the result of the operation *and* the
> value bound to a name - it isn't unique to the "given" keyword specifically)
>
> While the leading keyword would allow TARGET to be an arbitrary assignment
> target without much chance for confusion, it could also be restricted to
> simple names instead (as has been done for PEP 572.
>
> With that spelling, the three examples above would become:
>
>     # Exactly one branch is executed here
>     if m given m = pattern.search(data):
>         ...
>     elif m given m = other_pattern.search(data)):
>         ...
>     else:
>         ...
>
>     # This name is rebound on each trip around the loop
>     while m given m = pattern.search(remaining_data):
>         ...
>
>     # "f(x)" is only evaluated once on each iteration
>     result = [(x, y, x/y) for x in data if y given y = f(x)]
>
> Constraining the syntax that way (at least initially) would avoid poking
> into any dark corners of Python's current scoping and expression execution
> ordering semantics, while still leaving the door open to later making
> "result given NAME = expr" a general purpose ternary operator that returns
> the LHS, while binding the RHS to the given name as a side effect.
>
> Using a new keyword (rather than a symbol) would make the new construct
> easier to identify and search for, but also comes with all the downsides of
> introducing a new keyword. (Hence the not-entirely-uncommon suggestion of
> using "with" for a purpose along these lines, which runs into a different
> set of problems related to trying to use "with" for two distinct and
> entirely unrelated purposes).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180504/ded3f883/attachment-0001.html>