Author vinay.sajip
Recipients jsbronder, r.david.murray, vinay.sajip
Date 2015-07-17.00:32:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1437093162.44.0.994342072213.issue24645@psf.upfronthosting.co.za>
In-reply-to
Content
I agree the lock could be seen as redundant as there are no shared data structures used by the current implementation of the enqueue and prepare methods (which are called after the lock is acquired), but users could potentially override those methods in subclasses in ways that require locking to be thread-safe. Currently, people overriding emit() [or code called from there] know that any state they manipulate there is protected by the handler lock - and this would not be the case if I implemented your suggestion. It could certainly break subclasses of QueueHandler which are out there in the wild.

Note that the reference to locking is there in the Handler.handle docstring - https://docs.python.org/library/logging.html#logging.Handler.handle - so changing it would change the contract which is documented.
History
Date User Action Args
2015-07-17 00:32:42vinay.sajipsetrecipients: + vinay.sajip, r.david.murray, jsbronder
2015-07-17 00:32:42vinay.sajipsetmessageid: <1437093162.44.0.994342072213.issue24645@psf.upfronthosting.co.za>
2015-07-17 00:32:42vinay.sajiplinkissue24645 messages
2015-07-17 00:32:41vinay.sajipcreate