Platform default thread stack sizes vary considerably.
Some are very generous (Win32: usually 1MB; Linux: 1MB,
sometimes 8MB).  Others are not (FreeBSD: 64k).

Some platforms have restricted virtual address space
OS/2: 512M less overhead) which makes hard coding a
generous default thread stack size problematic.  Some
platforms thread commit stack address space, even
though the memory backing it may not be committed
(Windows, OS/2 at least).

Some applications have a thirst for stack space in
threads (Zope). Some programmers want to be able to use
lots of threads, even in the face of sound advice about
the lack of wisdom in this approach.

The current approach to stack space management in
threads in Python uses a hard coded strategy, relying
on the platform having a useful default or relying on
the system administrator or distribution builder
over-riding the default at compile time.

This patch is intended to allow developers some control
over managing this resource from within Python code by
way of a function in the thread module.  As written, it
is not intended to provide unlimited flexibility; that
would probably require exposing the underlying
mechanism as an option on the creation of each thread.

An alternative approach to providing the functionality
would be to use an environment variable to provide the
information to the thread module.  This has its pros
and cons, in terms of flexibility and ease of use, and
could be complementary to the approach implemented.

The patch has been tested on OS/2 and FreeBSD 4.8.  I
have no means of testing the code on Win32 or Linux,
though Linux is a pthread environment as is FreeBSD. 
Code base is SVN head from a few hours ago. A doc 
update is included.

While I would like to see this functionality in Python
2.5, it is not a critical issue.

Critique of the approach and implementation welcome. 
Something not addressed is the issue of tests,
primarily because I haven't been able to think of a
viable testing strategy - I'm all ears to suggestions
for this.