[Python-Dev] Call for prudence about PEP-572
On 7/8/2018 1:23 PM, Chris Angelico 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:
>>> But the PEP 8 spellings are
>>> f(x := 1).
>>> The extra spacing makes it obvious that this isn't a regular named
>> 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.
> Python's grammar has a number of weird edge cases due to necessity
> (for instance, "for x in a if cond else b:" works, but not in a
> comprehension), and when there's an actual conflict, sure, you can say
> "but nobody would ever want to do that, so we'll forbid it". In this
> case, there is no conflict.
I agree with Chris in this case. That said, there is at least one place
where the grammar does forbid you from doing something that would
otherwise make be allowable: decorators.
File "<stdin>", line 1
SyntaxError: invalid syntax
But this works:
>>> new_decorator = lookup
... def f(): pass
Thus, the idea of restricting the type of expression that can be used in
particular circumstances is not without precedent, and should not be
dismissed at face value. That is, unless we want to remove the
restriction on decorators, which I'm okay with, too. I have occasionally
wanted to do something more complicated with a decorator, and used the