[Email-SIG] Design Thoughts Summary

[Matthew Dixon Cowles]

[R. David Murray]

> I'm including it here to make it easier for people to comment.

Thank you. I am virtually 100% in agreement that this document
represents what people have agreed on and that it represents what is
sensible to do.

>      - For non-conforming input, when is it OK to raise an error and
>        return to the calling client rather than handle it? (The 
>        answer to this is probably 'never').

I continue to vote for never. Mostly because it would amount to
providing the same information in more than one way.

Consider code like this:

    m=email.message_from_bytes(b)
    for defect in m:
      # See how bad the message is and
      # decide what to do with it

If the parser raised parsing exceptions, I'd need something like:

    try:
      m=email.message_from_bytes(b)
    except email.ParseError:
      # Message is very bad
    else:
      for defect in m:
        # See how bad the message is

Hardly impossible to write, but I don't see the point in making every
use of the parser look like that.

> * The API needs to at a minimum have hooks available for an
> application to store data on disk rather than holding everything in
> memory.

I remain unconvinced that this is worth the trouble. Yes, the Twisted
folks say that they can't use the email module because they may be
receiving hundreds of messages at once. But can anyone do anything
with hundreds of messages at once other than write them to disk?

And would anything actually be improved by reading hundreds of files
at once, in small chunks, looking for MIME separators?

Regards,
Matt