[Python-ideas] Inline assignments using "given" clauses
python at fwdaddr.fastmail.fm
Thu May 10 22:31:00 EDT 2018
Hi all. I've been lurking for a little while on this discussion and I
thought I might contribute some thoughts.
One of my hurdles for ":=" is understanding when I should use it rather
than "=". Should I use it everywhere? Should I use it only where I can't
use regular "="? Is it a personal choice? Will it become so common that
I need to think harder because some people will use it really frequently
or intermix them?
When I work on a different codebase, am I going to have to follow an
"always" or "never" for binding expressions? Maybe this is all overblown
and PEP8 direction will keep everyone on the same page, but I guess I
worry about there being 2 very similar, but not the same, ways to do it.
What I really like about "given" is it makes it a lot clearer when I
should use it. No one is going to want to write
x given x = f()
if they can just write
x = f()
If you need a binding expression in a comprehension or an if or while
statement, you'll know the pattern of using "given" to save that loop
and a half or to call a function and bind its result while iterating.
Just like you know when to use a ternary if to save that extra temporary
variable - there's little confusion about when to use a ternary,
especially since a few if statements quickly prove clearer to read.
10 if x == 5 else 9 if x == 2 else 8 if x == 3 else 100
looks much better as:
if x == 5:
result = 10
elif x == 2:
result = 9
elif x == 3:
result = 8
result = 100
I feel the same way about given. If you feel tempted to go
x given x = y * 2 given y = z + 3 given z = f()
Which should be equivalent to:
x := (y := ((z := f()) + 3)) * 2
hopefully you'll think, "maybe I should just make 3 statements instead?"
And also I have no trouble following what that statement actually does
when using given. I didn't need any parenthesis to make sure I didn't
bind the wrong expressions and I don't have to read it from the inside
out. Each sub-expression is complete rather than being mixed together
(even though I have to read it from right to left).
I feel like the strongest argument for ":=" is for all the situations
where someone will actually want a binding expression in real code, ":="
is more succinct. I'm just concerned that when given a new binding
expression hammer, everything is going to look like a nail and all the
places where someone could really benefit from a binding expression will
be drowned out by the unnecessary usage of ":=" (and its side effects).
----- Original message -----
From: Guido van Rossum <guido at python.org>
To: "marky1991 ." <marky1991 at gmail.com>
Cc: "python-ideas" <python-ideas at python.org>
Subject: Re: [Python-ideas] Inline assignments using "given" clauses
Date: Thu, 10 May 2018 11:10:50 -0400
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.)
On Thu, May 10, 2018 at 10:26 AM, marky1991 . <marky1991 at gmail.com> wrote:> If it just needs a stream of +1s, I personally like the "given"
> approach much more than the ":=" approach, for all of the many reasons
> repeated many times in the various email chains. (I preferred it as
> "as", but that's been struck down already) (and if it's between ":="
> and not having them at all, I would rather just not have them)
--Guido van Rossum (python.org/~guido)
Python-ideas mailing list
Python-ideas at python.org
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas