On 11 April 2018 at 06:32, Chris Angelico <ros...@gmail.com> wrote: > When a class scope is involved, a naive transformation into a function would > prevent name lookups (as the function would behave like a method). > > class X: > names = ["Fred", "Barney", "Joe"] > prefix = "> " > prefixed_names = [prefix + name for name in names] > > With Python 3.7 semantics, this will evaluate the outermost iterable at class > scope, which will succeed; but it will evaluate everything else in a > function:: > > class X: > names = ["Fred", "Barney", "Joe"] > prefix = "> " > def <listcomp>(iterator): > result = [] > for name in iterator: > result.append(prefix + name) > return result > prefixed_names = <listcomp>(iter(names)) > > The name ``prefix`` is thus searched for at global scope, ignoring the class > name. Under the proposed semantics, this name will be eagerly bound, being > approximately equivalent to:: > > class X: > names = ["Fred", "Barney", "Joe"] > prefix = "> " > def <listcomp>(prefix=prefix): > result = [] > for name in names: > result.append(prefix + name) > return result > prefixed_names = <listcomp>()
Surely "names" would also be eagerly bound, for use in the "for" loop? [...] > > This could be used to create ugly code! > --------------------------------------- > > So can anything else. This is a tool, and it is up to the programmer to use > it > where it makes sense, and not use it where superior constructs can be used. Related objection - when used to name subexpressions in a comprehension (one of the original motivating use cases for this proposal), this introduces an asymmetry which actually makes the comprehension harder to read. As a result, it's quite possible that people won't want to use assignment expressions in this case, and the use case of precalculating expensive but multiply used results in comprehensions will remain unanswered. I think the response here is basically the same as the above - if you don't like them, don't use them. But I do think the additional nuance of "we might not have solved the original motivating use case" is worth a specific response. Overall, I like this much better than the previous proposal. I'm now +1 on the semantic changes to comprehensions, and barely +0 on the assignment expression itself (I still don't think assignment expressions are worth it, and I worry about the confusion they may cause for beginners in particular). Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
