I haven't gotten to writing that into the PEP yet, but I think the rule has to be to take the scope of evaluation not the scope of definition. I know it needs to be there, and I'm just thinking about helpful examples.
Which is to say the semantics are more like `eval()` than like a lambda closure.
... and I know this is going to raise the neck hairs of many folks, because effectively I'm proposing a kind of dynamic scoping.
I’ll be curious to see the rationale for this in the PEP, because it seems like clearly the wrong choice to me. It turns the feature from “delayed computation” into something much stranger that I doubt I would support.
If the motivation is “so it can be used in argument default values and subsume PEP 671,” I think that’s a bad reason. IMO putting complex default values that would require delayed evaluation into the function signature line is net harmful (because of the pass through problem) so I oppose both PEP 671 and the use of deferred evaluation for that purpose.
Possibly in my defense, I think Carl's PEP 690 can do the same thing. :-)
I’m not sure what you mean. I don’t think there’s any way PEP 690 can introduce dynamic scoping like this. Can you give an example?
Carl