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 | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4