Author barry
Recipients barry, ncoghlan, r.david.murray, sblondon, serhiy.storchaka
Date 2017-12-10.23:11:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1512947519.97.0.213398074469.issue32234@psf.upfronthosting.co.za>
In-reply-to
Content
It's possible that the Mailman example can just assume that the mailbox will be flushed and unlocked on __exit__(), so it could just call .close().  Then the question is whether entering the CM should lock the mailbox.  The two cases are:

1. It doesn't, so you'd have to do:

with mbox(...) as mb:
    mb.lock()
    # ...

2. It does, so if for some reason you didn't want the lock, you'd have to:

with mbox(...) as mb:
    mb.unlock()

We *could* add a `lock` argument to the constructor to take the ambiguity away.  But I would claim that it doesn't make much sense to acquire an mbox in a CM and *not* lock it.  The idiom says to me "I want to do things to the mbox, exclusively, and if that requires locking it, JFDI".

So I would argue that the __enter__() should acquire the lock by default if the underlying mailbox supports it.
History
Date User Action Args
2017-12-10 23:11:59barrysetrecipients: + barry, ncoghlan, r.david.murray, serhiy.storchaka, sblondon
2017-12-10 23:11:59barrysetmessageid: <1512947519.97.0.213398074469.issue32234@psf.upfronthosting.co.za>
2017-12-10 23:11:59barrylinkissue32234 messages
2017-12-10 23:11:59barrycreate