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,
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 rea
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 barel
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 depl
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
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
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?), and already you
>are talking about adding more stuff. P
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 been
> > implemented (did it survive the AST-branc
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 s
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. :)
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 discussi
Nick Coghlan wrote:
> P.S. Here's a different generator wrapper that could be used to create a
> generator-based "suspendable context" that can be invoked multiple times
> through use of the "without" keyword. If applied to the PEP 343
> decimal.Context() __with__ method example, it would automa
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'r
"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
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 s
"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 acce
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.
PEP: XXX
Title: Task-local Variables
Autho
17 matches
Mail list logo
