_PyRLock is not used directly. Instead, no _CRLock is provided, so the threading.RLock function calls _PyRLock.<div><br></div><div>It&#39;s done this way because green threading libraries may only provide a greened lock. _CRLock in these contexts would not work: It would block the entire native thread.</div>
<div><br></div><div>I suspect that if you removed _PyRLock, these implementations would have to expose their own RLock primitive which works the same way as the one just removed from the standard library. I don&#39;t know if this is a good thing.</div>
<div><br></div><div>I would recommend checking with at least the gevent and eventlet developers.<br><br><div class="gmail_quote">2012/1/7 Charles-François Natali <span dir="ltr">&lt;<a href="mailto:neologix@free.fr">neologix@free.fr</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for those precisions, but I must admit it doesn&#39;t help me much...<br>
Can we drop it? A yes/no answer will do it ;-)<br>
<br>
&gt; I&#39;m pretty sure the Python version of RLock is in use in several alternative<br>
&gt; implementations that provide an alternative _thread.lock. I think gevent<br>
&gt; would fall into this camp, as well as a personal project of mine in a<br>
&gt; similar vein that operates on python3.<br>
<br>
Sorry, I&#39;m not sure I understand. Do those projects use _PyRLock directly?<br>
If yes, then aliasing it to _CRLock should do the trick, no?<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>ಠ_ಠ<br>
</div>