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