[Steven D'Aprano <st...@pearwood.info>] >>> ... >>> average = 0 >>> smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal] >>> assert average == smooth_signal[-1]
[Tim] >> The scope issues are logically independent of assignment-expression >> spelling, but it's a pretty safe guess Nick is opposed to that example >> ever "just working" regardless of spelling, while PEP 572 doesn't >> currently support it anyway. [Nick Coghlan <ncogh...@gmail.com>] > I'm personally fine with that example working "Just working" meant "exactly as written". "Regardless of spelling" meant whether binding is spelled via ":=", "given", "as", "where", "let ... in ...' "->", .. > if there's an explicit nonlocal declaration on "average" in the nested > scope - it's Guido that objected to requiring the explicit scoping > declaration to access that behaviour. I suspect, but don't know, that Guido would like that example to "just work" because it _looks like_ it should "just work". There's no visible function involved, and _needing_ to add scope declarations to make it work is pretty much inexplicable unless the user first learns more than most users "should" need to learn about how it's implemented. If so, no technical argument will change his mind - and especially not one based on "but the implementation today doesn't do that already". Recall that Python had no lexically nested scoping at first? If he wanted to _make_ users learn about nested lexical scopes to use Python features that don't _appear_ to use it, Python would have had it from the start ;-) I'd be happy enough with needing an explicit declaration too, but am _happiest_ with what I'm guessing Guido's view is. > For the implicit version, my request is that any PEP proposing the idea of > parent local scoping be held to the standard of *actually drafting the patch > for the language specification*, Of course. > rather than handwaving away the hard problems that it creates > (i.e. what to do at class scope, I finally looked at class scope and quickly decided it makes no sense there (a comprehension at class scope has no access to the class scope, so "same scope in the comprehension as in its immediately containing block" is incoherent in that case). > what to do when multiple generators expressions reference the same > nonlocal name, Then, as you said, they access the same nonlocal name. What of it? What if two generator functions reference (or even rebind) the same nonlocal name? What's unclear about that? If you were happy with explicit scope declarations, then exactly the same thing would happen as if the user were forced to explicitly declare the scopes chosen for them. > what to do with nested comprehensions, Again, if you were happy with explicit scope declarations, then exactly the same ... Where are the docs explaining how nested comprehensions work today? I haven't seen any. If any such exist, I'd bet nothing about them needs to be changed. If none such exist, I don't see a need to write any just for this PEP. How do nested expressions of any kind work? Same thing. The only thing the suggestion changes is the scope of assignment expression targets in synthetic functions created to implement comprehensions. That has nothing at all to do with the possibility of nesting, or with the structure of nesting. Why do you think it does - or might? > how to expand comprehensions using this kind of scoping to their statement > form in a context independent way). I've already explained why I view that as a non-issue (making a tedious manual process a relative handful of users undertake once in their life for self-education purposes slightly less tedious has approximately no value to me - and, to the contrary, the "context dependent" bits they may have to learn would make it _more_ educational). If that's a show-stopper for you, so be it. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
