> Note that another solution would be to use a dedicated thread for
> signal management (like Java does), but that's another story.

That sounds like a good solution in the middle-term. Are there any
drawbacks? (apart from launching a thread)

> Also, this shouldn't be a problem for the buffered I/O code, since the
> code already accounts for this possibility (if the lock is already
> acquired by the current thread, an exception is raised).

Yes, but raising an exception is less helpful than doing what the user
asked for :)

> Now, there's something I don't understand: I've just had a quick look,
> but AFAICT, there's no reason why the C version of RLock could not be
> available: am I missing something? Why do we even have a Python
> implementation?

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)