[Python-Dev] usefulness of Python version of threading.RLock (original) (raw)

Matt Joiner anacrolix at gmail.com
Fri Jan 6 07:11:37 CET 2012

I'm pretty sure the Python version of RLock is in use in several alternative implementations that provide an alternative _thread.lock. I think gevent would fall into this camp, as well as a personal project of mine in a similar vein that operates on python3.

2012/1/6 Charles-François Natali <neologix at free.fr>

Hi,

Issue #13697 (http://bugs.python.org/issue13697) deals with a problem with the Python version of threading.RLock (a signal handler which tries to acquire the same RLock is called right at the wrong time) which doesn't affect the C version. Whether such a use case can be considered good practise or the best way to fix this is not settled yet, but the question that arose to me is: "why do we have both a C and Python version?". Here's Antoine answer (he suggested to me to bring this up on python-dev": """ The C version is quite recent, and there's a school of thought that we should always provide fallback Python implementations. (also, arguably a Python implementation makes things easier to prototype, although I don't think it's the case for an RLock) """ So, what do you guys think? Would it be okay to nuke the Python version? Do you have more details on this "school of thought"? Also, while we're at it, Victor created #13550 to try to rewrite the "logging hack" of the threading module: there again, I think we could just remove this logging altogether. What do you think? Cheers, cf

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com

-- ಠ_ಠ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120106/265192b4/attachment.html>

More information about the Python-Dev mailing list