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 <neolo...@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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > -- ಠ_ಠ
_______________________________________________ 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