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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to