Author ncoghlan
Recipients barry, ncoghlan, r.david.murray, sblondon, serhiy.storchaka, yselivanov
Date 2017-12-07.00:17:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1512605856.17.0.213398074469.issue32234@psf.upfronthosting.co.za>
In-reply-to
Content
I don't know the mailbox API particularly well, but the fact the object offers all three of lock(), unlock() and close() as methods does imply a fair bit of inherent ambiguity.

One option would be to offer a module level "mailbox.locked()" API to handle the lock/unlock case, and then have native context management on the mailbox itself that was akin to "contextlib.closing".


(Note regarding contextlib.locked(): the reason we don't currently have that is because there's no consistent protocol for locking method names. acquire()/release() and lock()/unlock() would be the most popular pairings, so we could technically offer both "contextlib.acquired()" and "contextlib.locked()", but the duplication still seems a bit dubious to me)
History
Date User Action Args
2017-12-07 00:17:36ncoghlansetrecipients: + ncoghlan, barry, r.david.murray, serhiy.storchaka, yselivanov, sblondon
2017-12-07 00:17:36ncoghlansetmessageid: <1512605856.17.0.213398074469.issue32234@psf.upfronthosting.co.za>
2017-12-07 00:17:36ncoghlanlinkissue32234 messages
2017-12-07 00:17:36ncoghlancreate