[Python-Dev] Pre-PEP: Task-local variables
ncoghlan at gmail.com
Fri Oct 21 17:08:43 CEST 2005
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
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
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
# 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.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev