(original) (raw)
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@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
ಠ\_ಠ