[Python-Dev] Pre-PEP: Task-local variables

[Nick Coghlan]

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
> resorted to per-thread context. Even that doesn't always do the right
> thing -- handling decimal contexts is surprisingly subtle (as Nick can
> testify based on his experiences attempting to write a decimal context
> manager for the with-statement!).

Indeed. Fortunately it isn't as complicated as I feared last night (it turned 
out to be a problem with me trying to hit a small nail with the new 
sledgehammer I was playing with, forgetting entirely about the trusty old 
normal hammer still in the toolkit).

> But I haven't seen the use case yet for mixing coroutines with changes
> to decimal context settings; somehow it doesn't strike me as a likely
> use case (not that you can't construct one, so don't bother -- I can
> imagine it too, I just think YAGNI).

For Python 2.5, I think the approach of generators explicitly reverting 
altered contexts around yield expressions is a reasonable way to go.

This concept is workable for generators, because they *know* when they're 
going to lose control (i.e., by invoking yield), whereas it's impossible for 
threads to know when the eval loop is going to drop them in favour of a 
different thread.

I think the parallel between __iter__ and __with__ continues to work here, too 
- alternate context managers to handle reversion of the context (e.g., 
Lock.released()) can be provided as separate methods, just as alternative 
iterators are provided (e.g., dict.iteritems(), dict.itervalues()).

Also, just as we eventually added "itertools" to support specific ways of 
working with iterators, I expect to eventually see "contexttools" to support 
specific ways of working with contexts (e.g. duck-typed contexts like 
"closing", or a 'nested' context that allowed multiple resources to be 
properly managed by a single with statement).

contexttools would also be the place for ideas like suspending and resuming a 
context - rather than requiring specific syntax, it could be implemented as a 
context manager:

   ctx = suspendable_context(EXPR)
   with ctx as VAR:
     # VAR would still be the result of (EXPR).__with__().__enter__()
     # It's just that suspendable_context would be taking care of
     # making that happen, rather than it happening the usual way
     with ctx.suspended():
       # Context is suspended here
     # Context is resumed here

I do *not* think we should add contexttools in Python 2.5, because there's far 
too much chance of YAGNI. We need experience with the 'with' statement before 
we can really identify the tools that are appropriate.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com