Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Wow, that was quick. Did you try to replace threading.RLock with your implementation, and run the tests?
By the way: > - acquire() method argument "blocking" is not a keyword > - In the Python version, RLock._release_save() replaces owner and > counter attributes before release the lock. But releasing the lock may > fails and no the object is in an inconsistent state Removing the debugging statements is fine, but apart from that the C implementation should mimick the current behaviour. Even if this behaviour has potential pitfalls. Speaking of which, it would be nice if RLock was subclassable. I don't know whether any software relies on this though. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3001> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
