Guido van Rossum [EMAIL PROTECTED] writes:
On 10/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:57 AM 10/20/2005 -0700, Guido van Rossum wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely been
Phillip J. Eby wrote:
Actually, it's fairly simple to write a generator decorator using
context.swap() that saves and restores the current execution state
around next()/send()/throw() calls, if you prefer it to be the
generator's responsibility to maintain such context.
Yeah, I also
Guido van Rossum wrote:
If it weren't for Python's operator overloading, the decimal module
would have used explicit contexts (like the Java version); but since
it would be really strange to have such a fundamental numeric type
without the ability to use the conventional operator notation, we
Phillip J. Eby wrote:
This is still rather rough, but I figured it's easier to let everybody fill
in the remaining gaps by arguments than it is for me to pick a position I
like and try to convince everybody else that it's right. :) Your feedback
is requested and welcome.
I think you're
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely been
implemented (did it survive the AST-branch merge?), and already you
are talking about adding more stuff. Please put on the brakes!
If there's anything this
At 10:40 PM 10/20/2005 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
This is still rather rough, but I figured it's easier to let everybody
fill
in the remaining gaps by arguments than it is for me to pick a position I
like and try to convince everybody else that it's right. :) Your
On 10/20/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely been
implemented (did it survive the AST-branch merge?), and already you
are talking about adding more stuff.
On 10/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:04 PM 10/20/2005 -0400, Jeremy Hylton wrote:
On 10/20/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely
On 10/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 08:57 AM 10/20/2005 -0700, Guido van Rossum wrote:
Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
PEP 343 is still (back) on the drawing table, PEP 342 has barely been
implemented (did it survive the AST-branch merge?),
At 07:57 PM 10/20/2005 -0700, Guido van Rossum wrote:
(Sorry for the long post -- there just wasn't anything you said that I
felt could be left unquoted. :-)
Wow. You've brought up an awful lot of stuff I want to respond to, about
the nature of frameworks, AOP, Chandler, PEP 342, software
Phillip J. Eby [EMAIL PROTECTED] wrote:
For efficiency's sake, however, CPython could simply store the
execution context dictionary in its thread state structure, creating
an empty dictionary at thread initialization time. This would make it
somewhat easier to offer a C API for access to
At 07:30 PM 10/19/2005 -0700, Josiah Carlson wrote:
What about a situation in which corutines are handled by multiple
threads? Any time a corutine passed from one thread to another, it
would lose its state.
It's the responsibility of a coroutine scheduler to take a snapshot() when
a task is
Phillip J. Eby [EMAIL PROTECTED] wrote:
It's the responsibility of a coroutine scheduler to take a snapshot() when
a task is suspended, and to swap() it in when resumed. So it doesn't
matter that you've changed what thread you're running in, as long as you
keep the context with the
13 matches
Mail list logo
