On Sun, Jul 8, 2018 at 7:24 PM Chris Angelico <ros...@gmail.com> wrote: > > On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' <g.rod...@gmail.com> wrote: > > > > > > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden <st...@holdenweb.com> wrote: > >> > >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' <g.rod...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com