[Python-Dev] usefulness of Python version of threading.RLock

Eric Snow ericsnowcurrently at gmail.com
Thu Jan 5 23:02:42 CET 2012


2012/1/5 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"?

>From what I understand, the biggest motivation for pure Python
versions is cooperation with the other Python implementations.  See
http://www.python.org/dev/peps/pep-0399/

-eric

>
> 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/ericsnowcurrently%40gmail.com


More information about the Python-Dev mailing list