to avoid relying on atexit.
Will backport to 2.5.

Heavily revised, comprising revisions:
46640 - original trunk revision (backed out in r46655)
46647 - markup fix (backed out in r46655)
46692:46918 merged from branch aimacintyre-sf1454481

branch tested on buildbots (Windows buildbots had problems
not related to these changes).

46640 Patch #1454481:  Make thread stack size runtime tunable.
46647 Markup fix

The first is causing many buildbots to fail test runs, and there
are multiple causes with seemingly no immediate prospects for
repairing them.  See python-dev discussion.

Note that a branch can (and should) be created for resolving these
problems, like

svn copy svn+ssh://svn.python.org/python/trunk -r46640 svn+ssh://svn.python.org/python/branches/NEW_BRANCH

followed by merging rev 46647 to the new branch.

discussion.
There are two places of documentation that still mention __context__:
Doc/lib/libstdtypes.tex -- I wasn't quite sure how to rewrite that without
spending a whole lot of time thinking about it; and whatsnew, which Andrew
usually likes to change himself.

this can just call __context__ on the underlying lock.
(The same change for Semaphore does *not* work!)

Anyway, this is the changes to the with-statement
so that __exit__ must return a true value in order
for a pending exception to be ignored.
The PEP (343) is already updated.

- New semantics for __exit__() -- it must re-raise the exception
  if type is not None; the with-statement itself doesn't do this.
  (See the updated PEP for motivation.)

- Added context managers to:
  - file
  - thread.LockType
  - threading.{Lock,RLock,Condition,Semaphore,BoundedSemaphore}
  - decimal.Context

- Added contextlib.py, which defines @contextmanager, nested(), closing().

- Unit tests all around; bot no docs yet.

exception (e.g., passing in an illegal argument).

Applies patch #1314396.  Thanks Eric Blossom.

Closes bug #1110998.  Thanks Matthew Bogosian.

test_threading.test_foreign_thread():  new test does a basic check that
"foreign" threads can using the threading module, and that they create
a _DummyThread instance in at least one use case.  This isn't a very
good test, since a thread created by thread.start_new_thread() isn't
particularly "foreign".

_Thread.__init__) was never used.  This is a waste since locks use OS
primitives that are in limited supply.  So the lock is deleted in
_DummyThread.__init__ .

Closes bug #1089632.

rather than in docstrings.  Rewrote so that _active_limbo_lock is released
no matter what happens (it could have been left locked if _sys got None'd
out).  Use "in" in preference to has_key() for dict lookup.  Don't bother
looking for 'dummy_threading' in sys.modules unless KeyError is raised.
Since the heart of the method is the del, do that in only one place.

and Thread.__delete() was called after a Thread instance was created.  Problem
resulted from a currentThread() call in an 'assert' statement being optimized
out and dummy_thread.get_ident() always returning -1 and thus overwriting the
entry for the _MainThread() instance created in 'threading' at import time.

Closes bug #993394.

http://mail.python.org/pipermail/python-dev/2004-June/045785.html

during interpreter shutdown instead of masking it with another traceback about
accessing a NoneType when trying to print the exception out in the first place.

Closes bug #754449 (using patch #954922).

Side-effects were deemed unnecessary and were causing problems at shutdown
time when threads were catching exceptions at start time and then triggering
exceptions trying to call currentThread() after gc'ed.  Masked the initial
exception which was deemed bad.

Fixes bug #754449 .

* Add unittests, newsitem, and whatsnew
* Apply to Queue.py mutex.py threading.py pydoc.py and shlex.py
* Docs are forthcoming

mostly for convenience and to aid debugging.

Jeremy can check in the real things.

- when the thread module isn't available, subsequent attempts to import
  threading should not suceed

interrupted.  A try/finally will do nicely.  Maybe other classes need
this too, but since they manipulate more state it's less clear that
that is always the right thing, and I'm in a hurry.

Backport candidate.

the finally clause.  An exception here could happen when a daemon
thread exits after the threading module has already been trashed by
the import finalization, and there's not much of a point in trying to
insist doing the cleanup in that stage.

This should fix SF bug ##497111: active_limbo_lock error at program
exit.

2.1.2 and 2.2.1 Bugfix candidate!