On Mon, May 07, 2018 at 10:38:09AM -0700, Guido van Rossum wrote: > The only solution that makes sense to me is Steven's (2). (1) is what the > PEP currently says and what Tim doesn't want; (3) has no precedent > (function defaults don't really work like this) and just gets my hackles > all up. (I can't even tell if Steven meant it as a serious proposal.)
It doesn't get my hackles up as much as you, but its not really what I want. It's just a compromise between what I *don't* want (1), which fails to solve the original motivating example that started this discussion, and what Chris was pushing back against (2). > There's one corner case (again) -- class scopes. If the containing scope is > a function, everything's fine, we can use the existing closure machinery. > If the containing scope is global, everything's fine too, we can treat it > as a global. But if the containing scope is a class, we can't easily extend > the current machinery. But this breakage is similar to the existing > breakage with comprehensions in class scope that reference class variables: [...] > I propose to punt on this case. If we want to fix it we can fix it in a > number of ways and the fix can easily apply to both getting and setting -- > but this is a separate fix (and we should take it out of PEP 572). +1 Whether the current class behaviour is "broken" or desirable or somewhere in between, it is what we have now and its okay if binding expressions have the same behaviour. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
