I was reading _threading_local and noticed it didn't use the with
statment, yet. So, I cooked up this trivial patch. I hope this isn't to
small. Thanks for your time.

Thanks! :)
Lot's of code doesn't use the with statement yet. Feel free to
contribute more fixes.

I appreciate the patch submission but am going to reject it.  The 
try/finally form is faster.  In general, I think we only want to do 
this in code that isn't performance critical and that would be made 
much cleaner.

Oh, I didn't know that with is slower than try/finally. It should get
documented that try/finally is better suited than with for performance
critical code.

Raymond, does your comment also apply to change at r60189 ? It is
exactly the same thing, in threading.py...

OTOH, _threading_local.py is not used by the standard library, except by
the dummy_threading module; threading.local normally comes from
threadmodule.c.

I don't think this module is performance critical. Maybe we can teach
"good practices" there.

In ceval.c, the "case WITH_CLEANUP" contains the following lines:
  /* XXX Not the fastest way to call it... */
  x = PyObject_CallFunctionObjArgs(x, u, v, w, NULL);

Maybe this is something not too difficult to improve?

Most platforms use the faster thread.LockType. Correct? Perhaps, since
this module is more a reference implementation and it is pointed to by
the threading docs (http://docs.python.org/lib/module-threading.html),
we should elect to take the more pythonic route on this.

Generally we don't document the speed differences between various 
alternatives.  One reason is that relative performance varies across 
releases and platforms.  Another reason is that the rule in this case 
is somewhat generic (inlined code is typically faster than making a 
call to the same code without in-lining.  Us developers are supposed to 
know that sort of thing or time it if we don't.

Amaury, please do revert 60189.  There is no reason to destabalize this 
code, slow it down, and introduce new dependencies.

Use of the with-statement is not in and of itself a "best practice".  
Where it really shines is in factoring-away repeated setup/teardown 
code.

Modules that serve as elemental building blocks (like threading, Queue, 
heapq, etc) need to have fast, clean code with as few dependencies as 
possible.  

Also, we should change/modernize something like asyncore or threading 
with a great deal of care and restraint.  It is too easy to introduce 
hard to find bugs in this code.  It took a long time for this code to 
stabalize and we should enjoy the benefits of its maturity.

Ok, I see your reasoning. I'm going to start going to through the rest
of the library for places with should be used.

FWIW, we don't usually document relative speeds (or even O(n) 
performance).  Those things are implementation dependent and can vary 
across releases.

In the case of the with-statement, it would seem self-evident 
that "with" does everything try/finally does and adds function call 
overhead, the __enter__/__exit dance, and possibly introducing a 
locally scoped variable with the "as" clause.

I've filed issue 2179 to see if it's possible to make with as fast as
try/finally.