Martin v. Löwis wrote:
> Nick Coghlan wrote:
>> Do we want to add a "released" context manager to the threading module for
>> 2.5?
>
> I don't think that should be added. I would consider it a dangerous
> programming style: if the lock merely doesn't "need" to be held (i.e.
> if it isn't necessary, but won't hurt), one should just keep holding
> the lock. If it is essential to release the lock, because the code
> would otherwise deadlock, the code should be dramatically revised
> to avoid that situation, e.g. by redefining the granularity of the
> lock, and moving the with statements accordingly.
That isn't always possible or practical, though - Python's own GIL is a case
where releasing it around long-running operations (such as blocking I/O
operations) that don't need it provides significant benefits for threaded
code, but redesigning the lock to use finer granularity causes its own problems.
I'm not going to argue particularly strongly (or at all, really) for this one,
since I think threading.Thread + Queue.Queue is a much better way to write
threaded Python programs. The blocking IO 'asynchronize' use case in PEP 319
was just something I happened to notice in looking back at the various PEP's
that were rejected in favour of PEP 343.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
