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

Gustavo Carneiro gjcarneiro at gmail.com
Thu May 10 12:10:02 EDT 2018

On Thu, 10 May 2018 at 16:49, Ed Kellett <e+python-ideas at kellett.im> wrote:

> On 2018-05-10 16:10, Guido van Rossum wrote:
> > Please no, it's not that easy. I can easily generate a stream of +1s or
> -1s
> > for any proposal. I'd need well-reasoned explanations and it would have
> to
> > come from people who are willing to spend significant time writing it up
> > eloquently. Nick has tried his best and failed to convince me. So the bar
> > is high.
> >
> > (Also note that most of the examples that have been brought up lately
> were
> > meant to illustrate the behavior in esoteric corner cases while I was
> > working out the fine details of the semantics. Users should use this
> > feature sparingly and stay very far away of those corner cases -- but
> they
> > have to be specified in order to be able to implement this thing.)
> Poor prospects, then, but I'll do my best.
> I think the most obvious argument (to me) favouring `given` over `:=` is
> that it separates the two things it's doing:
>     if m.group(2) given m = pattern.search(data):
> as opposed to the more-nested := version:
>     if (m := pattern.search(data)).group(2):
> which, at least to me, is more complicated to think about because it
> feels like it's making the .group() something to do with the assignment.
> Put another way, I think your use of parentheses when discussing the
> *pronunciation* of this thing is telling. It feels as though one needs
> to start in the middle and then go in both directions at once, first
> explaining the origin (or destination) of the operand in question in a
> parenthesized offshoot, and then switching context and describing what
> is done to it. It's midly mentally taxing. I'm sure we can all live with
> that, but I don't want to: Python's exceptionally-readable syntax is one
> of the bigger reasons I choose it.
> There's a striking parallel in C, where the well-known idiom:
>     while ((c = getchar()) != EOF) ...
> has an obviously-nicer alternative:
>     while (c = getchar(), c != EOF) ...
> Most people I show this to agree that it's nicer, despite the fact that
> it manages to repeat a variable name *and* use the comma operator. I
> don't have proof, but I'd suggest that unwrapping that layer of context
> for the reader imparts a significant benefit.
> The C example also provides a convenient test: if you think the former
> example is nicer, I can just give up now ;)

IMHO, all these toy examples don't translate well to the real world because
they tend to use very short variable names while in real world [good
written code] tends to select longer more descriptive variable names.

Try replacing "c" with  a longer name, like input_command, then it becomes:

    while ((input_command = getchar()) != EOF) ...

    while (input_command = getchar(), input_command != EOF) ...

In the second example, having to type the variable name twice is an
annoyance that adds almost nothing to readability, so I would definitely
prefer the first one.

The "given" proposals have the same issue.

(a shame we can't use "as", for reasons already stated, it would have been
perfect otherwise)

Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180510/b99b56f2/attachment.html>

More information about the Python-ideas mailing list