threading support in python

[Paul Rubin]

"sjdevnull at yahoo.com" <sjdevnull at yahoo.com> writes:
>  Throwing them out without careful consideration is a bad
>idea--ref-counting is _not_ simply one GC implementation among many, it
>actually offers useful semantics and the cost of giving up those
>semantics should be considered before throwing out refcounting.

It's too late to consider anything before throwing out refcounting.
Refcounting has already been thrown out (in Jython, IronPython, and
maybe PyPy).  It's just an implementation artifact of CPython and MANY
other language implementations have gotten along perfectly well
without it.

> (1) I think is here to stay, if you're going to tell programmers that
> their destructors can't make program-visible changes (e.g. closing the
> database connection when a dbconn is destroyed), that's a _huge_ change
> from current practice that needs serious debate.

We had that debate already (PEP 343).  Yes, there is some sloppy
current practice by CPython users that relies on the GC to close the
db conn.  That practice already fails in several other Python
implementations and with PEP 343, we now have a clean way to fix it.
I don't understand why you're so fixated on keeping the sloppy method
around.  The benefit is marginal at best.  If you want stack-like
deallocation of something, ask for it explicitly.