On Sun, Oct 31, 2021 at 6:50 PM Steven D'Aprano <st...@pearwood.info> wrote: > > On Sun, Oct 31, 2021 at 03:10:56PM +1100, Chris Angelico wrote: > > > (Side point: The current reference implementation allows assignment > > expressions inside default argument expressions, mainly because I > > didn't go to the effort of blocking them. But if you ever ACTUALLY do > > this, then..... *wat*) > > Why? The result is well-defined. It might not be *good* code, but let's > not be overzealous with banning legal code just because it is bad :-)
It's just because of the lack of clarity with where the variable is being defined. If we declare that argument expressions are evaluated in some sort of subcontext (like list comps are), then assignment expressions would no longer change the function's namespace. (Not to mention the confusion with early-bound expressions, where it would add a name to the surrounding scope - not a problem for the compiler, but confusing for humans.) By permitting it now, we make it harder to make such a change in the future. That said, though, I think that that change would be unlikely to be of value (with comprehensions, there's the inherent use of the iteration variable, which doesn't apply here), so it probably won't matter. > That's the job of linters and code reviews. > > In an early bound default, the walrus operator binds to a name in the > scope the expression is evaluated in, i.e. the surrounding scope. So a > top level function with a walrus: > > string = "hello" > def func(spam=(a:=len(string)), eggs=2**a): > return (spam, eggs) > > binds to a global variable `a`. > > Similarly, a walrus inside a late bound default should bind to a local > variable. The walrus doesn't get executed until the function namespace > is up and running, and the walrus is a binding operation, so it should > count as a local variable. > Yeah, that's how it's currently implemented. If we're willing to define that as a permanent feature, then the definition is clear, and it is indeed the job of linters and code review to reject this kind of horrible code :) ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GRC3BKDLCG5SDK5S4TNON64MWIR7K2LZ/ Code of Conduct: http://python.org/psf/codeofconduct/
