Michael Hudson:
This proposal seems a bit like an effort to make generators good at doing something that they aren't really intended -- or dare I say suited? -- for.
I think it is more an effort to use the right keyword, which has unfortunately already been claimed by generators (and linked to iterators). yield is a sensible way for code to say "your turn, but come back later". But at the moment, it means "I am producing an intermediate value", and the way to call that function is to treat it as an iterator (which seems to imply looping over a closed set, so don't send in more information after the initial setup). Should we accept that "yield" is already used up, or should we shoehorn the concepts until they're "close enough"?
So, here's a counterproposal!
with expr as var: ... code ...
is roughly:
def _(var): ... code ... __private = expr __private(_)
...
The need for approximation in the above translation is necessary because you'd want to make assignments in '...code...' affect the scope their written in,
To me, this seems like the core requirement. I see three sensible paths: (1) Do nothing. (2) Add a way to say "Make this function I'm calling use *my* locals and globals." This seems to meet all the agreed-upon-as-good use cases, but there is disagreement over how to sensibly write it. The calling function is the place that could get surprised, but people who want thunks seem to want the specialness in the called function. (3) Add macros. We still have to figure out how to limit their obfuscation. Attempts to detail that goal seem to get sidetracked. -jJ