On Mon, Oct 30, 2017 at 8:30 PM, Drew wrote:
> Yeah, a flag for IMAP4 objects sounds like it'd solve
> backwards-compatibility problems. E.g.
>
> imaplib.IMAP4_SSL(..., commit=manual/auto)
>
> As for handling errors with automatic commits, we should probably just
> defer to whatever Python IO doe
Yeah, a flag for IMAP4 objects sounds like it'd solve backwards-compatibility
problems. E.g.
imaplib.IMAP4_SSL(..., commit=manual/auto)
As for handling errors with automatic commits, we should probably just defer to
whatever Python IO does to remain consistent.
On Oct 30, 2017, 1:33 PM, at
But maybe if __exit__ is called with an exception it should roll back.
In any case it looks like your proposal could break existing code (e.g.
code that uses `with` depending on its current behavior, using some other
logic to decide whether to commit or not) and that feels difficult to
overcome. P
IMAP4.close closes the selected inbox and commits changes such as deletions. It
is not called on IMAP4.__exit__ (only logout is, which doesn't call close in
its call stack) however, so:
with imaplib.IMAP4_SSL(...) as i:
...
would fail to commit those changes. close must be explicitly invoke
