Barry A. Warsaw <[email protected]> added the comment:
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.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue32234>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
