Message2967

Because ThreadLocal tdict is static in PyLocal, making a second threading.local object in a single thread destroys the dict from the first local object.  Run the following code with your patch and then with CPython to see what I mean:

import threading
first = threading.local()
first.x = 7
print "After creation:", first.x
second = threading.local()
print "After creating a second:", first.x

I've attached a version of the patch that fixes that, and cleans up the logic in local_init a bit.  The way you'd written it, an initless subclass of a subclass of local that had an init would be unable to take args or kwargs even though it has a superclass that can reasonably handle them.  

I also added tests for that sort of sublclassing and the use of two locals in a single thread to your test_thread_local.py.  I think we can wait to bring _threading_local.py over to our Lib whenever we fix that module naming problem.  It seems like your test does everything in the doctest, and there's no need for _threading_local as a backup since we're always going to include PyLocal.  It might be worth filing a bug for the doctest problem though.

The only thing that's keeping me from committing my version is that I'm not sure where the version of thread.py you supplied came from.  What version of CPython was that in?  It's not 2.5: that version uses deque. As you well know, Jython doesn't have an implementation of deque quite yet :)  It probably will soon though...

One last thing: please add the .py files you want to add to Lib like I did in my patch unless they're identical to the ones in CPythonLib.  In that case, add them to CPythonLib.includes as you did for _threading_local.py  It's easier for me to figure out what merging in I need to do if they land in Lib.
File Added: thread_local_groves.diff