[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