[Python-Dev] Call for prudence about PEP-572

[Giampaolo Rodola']

Fair enough. I will. Sorry for the extra pressure at this particular stage.

On Mon, 9 Jul 2018 at 00:06, Guido van Rossum <guido at python.org> wrote:

> Since you CC'ed me explicitly I feel compelled to respond. I have read
> your reasoning, and I simply don't agree with it. A few months ago I would
> have happily explained why (there is a reason) but given the endless debate
> we've already seen I am simply too tired for another long email. Please
> give me the benefit of the doubt. The sky is not falling.
>
> On Sun, Jul 8, 2018 at 2:27 PM Giampaolo Rodola' <g.rodola at gmail.com>
> wrote:
>
>> On Sun, Jul 8, 2018 at 7:24 PM Chris Angelico <rosuav at gmail.com> wrote:
>> >
>> > On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' <g.rodola at gmail.com>
>> wrote:
>> > >
>> > >
>> > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden <steve at holdenweb.com>
>> wrote:
>> > >>
>> > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' <
>> g.rodola at gmail.com>
>> > >> wrote:
>> > >>>
>> > >>> [...]
>> > >>> I find that (space between the parentheses of a function call
>> statement)
>> > >>> too unnatural as a place where to put an assignment. It is not even
>> > >>> "guarded" by a keyword like "if" or  "while" which can help as
>> indicators
>> > >>> that an assignment may occur. Also, I think it's way too easy to
>> confuse it
>> > >>> with a keyword argument:
>> > >>>
>> > >>>     >>> foo(x = 1)  # keyword arg
>> > >>>     >>> foo(x := 1)  # assignment + value passing
>> > >>> [...]
>> > >>
>> > >>
>> > >> But the PEP 8 spellings are
>> > >>
>> > >>     foo(x=1)
>> > >>
>> > >> and
>> > >>
>> > >>    f(x := 1).
>> > >>
>> > >> The extra spacing makes it obvious that this isn't a regular named
>> > >> argument.
>> > >
>> > >
>> > > What if the author of the code I'm reading didn't respect PEP-8? I
>> don't
>> > > think it's fair to invoke PEP-8 as a counter-measure to obviate a
>> syntax
>> > > which can clearly be mistaken with something else simply by omitting 2
>> > > spaces. Not to mention that I don't see why anyone would want to
>> declare a
>> > > variable in there in the first place.
>> > >
>> >
>> > It's not about why someone would want to assign inside a function
>> > call. It's about why it should be forbidden. Perhaps nobody has a good
>> > reason to use THlS_OBJECT as a variable name, and it's potentially
>> > very confusing; but should the grammar of Python forbid it? No.
>> > Because there is no value in forbidding it.
>>
>> I'll try to give some reasons on why I think it should be forbidden.
>> In order of importance, more or less:
>>
>> 1) Because of readability and because it's ambiguous. foo(x := 1) and
>> foo(x = 1) are visually too similar and mean 2 completely different
>> things. And no, I don't think PEP-8 compliant variants are much
>> better:
>>     >>> foo(x := 1)
>>     >>> foo(x=1)
>> Good luck explaining the difference between the two to a beginner
>> including the introduction of PEP-8 concepts and why spaces are so
>> important in this case. The fact that spaces are more important here
>> than in other places alone makes me think this is unlikely a good
>> idea.
>>
>> 2) It's an incentive to write more compact code at the expense of
>> readability. I see := being used in "if" and "while" statements as
>> different in this regard. They imply an indented code block will
>> follow and the variables being set in the "if/while" statement will be
>> used right after that, supposedly in the very next line and *in that
>> block only*. This is what
>> https://github.com/python/cpython/pull/8122/files is all about,
>> really. There is no block in this case hence AFAICT this syntax is
>> only meant for writing one-liners.
>>
>> 3) := assignments in {if, while, yield, assert} statements are more
>> clearly noticeable because delimited by such keywords whereas a
>> function call can appear anywhere in the code. The only way to easily
>> track assignments such as foo(x := 1) is via linting.
>>
>> 4) IMO this is the main bit of PEP-572 which can be subject to serious
>> abuse. The value of "explicit is better than implicit" is an advanced
>> concept. We can't expect it can be grasped by everybody. Many folks
>> may be tempted to write one-liners at the top of a function and even
>> feel good about it because a bunch of lines were saved. Potentially *a
>> lot* of lines can be saved so it even more advanced users may be
>> tempted to use it. After all the language allows it +  "it's brand new
>> syntax so it must be good".
>>
>> 5) It has no keyword argument correspondence. If foo(x := 1) is
>> allowed then why this one is not?
>>     >>> foo(x=(x := 1))
>> (I don't think it should BTW: it's not pretty)
>>
>> 6) Differently from := usage in {if, while, comprehensions} no valid
>> use case which would justify its usage has been provided so far.
>> AFAICT the only valid use case is for writing one-liners.
>>
>> 7) Defining something in there just feels wrong (to me at least)
>>
>> 8) I'm pretty sure any linter would emit a warning by default so why
>> bother adding support for a brand new syntax which we already know it
>> would be discouraged anyway?
>>
>> 9) It goes against half of the Python Zen.
>>
>> --
>> Giampaolo - http://grodola.blogspot.com
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180709/aec1ce3a/attachment.html>