On Wed, 25 Apr 2018 18:52:34 -0700 Łukasz Langa lukasz@langa.pl wrote:
On 25 Apr, 2018, at 5:20 PM, Chris Angelico rosuav@gmail.com wrote:
On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
yselivanov.ml@gmail.com wrote:
Just yesterday this snippet was used on python-dev to show how great the new syntax is:
my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
To my eye this is an anti-pattern. One line of code was saved, but the other line becomes less readable. The fact that 'buf' can be used after that line means that it will be harder for a reader to trace the origin of the variable, as a top-level "buf = " statement would be more visible.
Making 'buf' more visible is ONLY a virtue if it's going to be used elsewhere. Otherwise, the name 'buf' is an implementation detail of the fact that this function wants both a buffer and a size.
You're claiming that := is nicer in this situation because it's
less
prominent than regular assignment and thus doesn't suggest that the name
stays visible later.
But as others said, := does make the name visible later until
the
enclosing scope ends. In fact, a large part of its appeal is that you
can use the result later (as in the re.search() example). Will it be
visible enough to the reaser in those cases then?
There seems to be a conflict there.
Not only, but seeing := hints that something special is
going on
(some inner expression is being bound to a name). So now we have to be
extra careful when reading and reviewing code written that people who
like using that syntactical feature.
I also wonder how long it will be before someone writes:
def f(arg):
global _lazy_value
if predicate(arg) and (_lazy_value := frobnicate()) > arg:
...
(or something similar with "nonlocal")
Regards
Antoine.