Oleg Broytman writes:
> > where not. By "punt" I mean return a special object containing as
> > much of the meta data for an object as it could recover, along with
> > the data itself as a blob.
>
> The special object is an instance of an exception class ;)
It could be, but it will be returned with return, not raise. ;)
> > I think (== hope) that this will sufficiently localize the issues
> > that even though only AttributeError would even be raised, it
> > will be obvious what went wrong.
>
> Not exactly. One can see an AttributeError, but what was the
> cause? why a parser has created a broken object? AttributeError
> doesn't preserve information from parser.
Who said it wouldn't? Granted, I didn't say it would, but in my
Content-Type: multipart/alternative
Content-Type: text/plain
Content-Type: text/html; parseable=no
example, I would expect the object returned to reflect that
structure. In particular the object representing the second MIME part
would indeed possess a valid Header member. I would also attach the
original data (which in the case of a missing separator might very
well overrun into other parts, etc), but it would *not* be accessible
via the usual methods (eg, definitely not from .flatten()).
So in fact it's not clear to me that you could ask for more
information than that.
> > I can think of no input for which the parser should *ever* throw an
> > exception.
>
> Are you saying that even a random garbage would be parsed to a Message
> of some kind? No headers, a single unparsed body?..
As long as it contains no NULs or high-bit-set octets, and is
separated into at least two parts, each less than 998 characters long,
by a CRLF, yes, I would definitely expect that an otherwise randomly
generated string would be parsed to a Message.
This Message should not be sendable because RFC 5322 requires the
presence of a From and a Date. However, if you were implementing a
sendmail-compatible MTA or LDA, you might very well wish to accept
such a thing on stdin, parse it to a Message, and then default the
>From and Date header fields appropriately, and add a Message-ID header
field. I would, anyway, wouldn't you?
Ah, yes, that's another use case, isn't it?!
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
