[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
[Guido]
Maybe. You're not the first one
Guido van Rossum [EMAIL PROTECTED] writes:
[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
Brian Sabbey [EMAIL PROTECTED] writes:
It is possible to implement thunks without them creating their own
frame. They can reuse the frame of the surrounding function. So a new
frame does not need to be created when the thunk is called, and, much
like with a yield statement, the frame is not
On Thu, Apr 28, 2005, Brian Sabbey wrote:
It is possible to implement thunks without them creating their own frame.
They can reuse the frame of the surrounding function. So a new frame does
not need to be created when the thunk is called, and, much like with a
yield statement, the frame
[Michael Hudson]
I think the making-generators-more-sexy thing is nice, but I'm think
that's almost orthogonal.
Not entirely. I agree that continue EXPR calling next(EXPR) which
enables yield-expressions is entirely orthogonal.
But there are already two PEPs asking for passing exceptions
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti)
and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding
function can share the same code. The thunk gets compiled into the
function the same way the
On 4/29/05, Brian Sabbey [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti)
and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding
function can share the same code. The
On 29 apr 2005, at 20.10, Brian Sabbey wrote:
[...] The thunk and its surrounding function can share the same
code. The thunk gets compiled into the function the same way the
body of a for loop would.
This seems really, truly, nasty! Wouldn't this require you to check
the source code of the
Greg Ewing [EMAIL PROTECTED] writes:
Are there any objective reasons to prefer a generator
implementation over a thunk implementation?
I, too, would like to see an answer to this question.
I'd like to see an answer in the PEP, too.
Cheers,
mwh
--
All obscurity will buy you is time enough
[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
Maybe. You're not the first one saying this
Guido van Rossum wrote:
The main advantage of thunks that I can see is that you can save the
thunk for later, like a callback for a button widget (the thunk then
becomes a closure).
Or pass it on to another function. This is something we
haven't considered -- what if one resource-acquision-
Guido van Rossum wrote:
Even without a block-statement, these two changes make yield look a
lot like invoking a thunk -- but it's more efficient, since calling
yield doesn't create a frame.
I like PEP 340 a lot, probably as much or more than any thunk ideas I've
seen. But I want to defend thunks
(BTW, I'm trying to update the PEP with a discussion of thunks.)
[Guido]
The main advantage of thunks that I can see is that you can save the
thunk for later, like a callback for a button widget (the thunk then
becomes a closure).
[Greg]
Or pass it on to another function. This is
13 matches
Mail list logo
