On 25 March 2018 at 01:03, Kirill Balunov <kirillbalu...@gmail.com> wrote:
> > > 2018-03-24 17:14 GMT+03:00 Nick Coghlan <ncogh...@gmail.com>: >> >> >> They can be distinguished, just not at module or function scope. To give >> a concrete example: >> >> ========== >> >>> class C: >> ... sequence = range(10) >> ... listcomp = [x for x in sequence] >> ... def works(data): >> ... return list(data) >> ... from_works = works(sequence) >> ... def fails(): >> ... return list(sequence) >> ... >> >>> C.listcomp >> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >> >>> C.from_works >> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >> >>> C.fails() >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> File "<stdin>", line 8, in fails >> NameError: name 'sequence' is not defined >> ========== >> >> I think I did have an implementation that didn't do the "outermost >> iterator is evaluated in the outer scope" dance early on (back when I was >> still working on the initial version of the iteration variable hiding, >> before it was merged to the Py3k branch), but quickly changed it because >> relying solely on closures broke too much code (in addition to the class >> namespace case, you can create a situation with similar constraints by >> passing a separate locals namespace to exec). >> >> Cheers, >> Nick. >> > > But is the example with the class appropriate in this context, it seems > that it is well understood why this example will fail, and `C.fails()` > should at least be a `@classmethod`:) From the docs: > >> Class definition blocks and arguments to exec() >> <https://docs.python.org/3/library/functions.html#exec> and eval() >> <https://docs.python.org/3/library/functions.html#eval> are special in >> the context of name resolution. A class definition is an executable >> statement that may use and define names. These references follow the normal >> rules for name resolution with an exception that unbound local variables >> are looked up in the global namespace. The namespace of the class >> definition becomes the attribute dictionary of the class. The scope of >> names defined in a class block is limited to the class block; it does not >> extend to the code blocks of methods – this includes comprehensions and >> generator expressions since they are implemented using a function scope. > > And if we cross out class, exec and eval cases - they don't work now, they > will not be affected in future. Are not these examples equivalent? > I don't follow what you're trying to say here. Comprehensions *do* work with class bodies, two-namespace exec, and two-namespace eval, and one of the consequences of the *way* they work that proposals for expression level name binding will all have to deal with is that the outermost iterable expression is evaluated in the containing scope rather than the implicitly nested one. Statement local name bindings would restrict any resulting name leakage from the outermost iterable to the affected statement, while regular name bindings would affect the entirety of the containing scope. The latter behavour is of the larger downsides of having expression level name bindings work the same way assignment statements do, since it recreates a variant of the original iterator variable name leakage that the introduction of the implicitly nested scope eliminated. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
