[Email-SIG] fixing the current email module

[Oleg Broytman]

On Thu, Oct 08, 2009 at 08:25:41PM +0900, Stephen J. Turnbull wrote:
> Oleg Broytman writes:
>  >    I disagree. email package is not a user agent, and exceptions are *the*
>  > way to indicate there are problems.
> 
> Although practicality beats purity.
> 
> The email package has access to the wire format, and knows what to do
> with most of it.  It should DTRT where that is possible, and punt
> 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 ;)

> I would suggest that module utilities that require access to the
> parsed form of data be designed as object methods.  The special
> objects produced when broken wire format is encountered wouldn't have
> those methods, and thus they'd fail the duck type test.  But that
> makes sense: that "duck" can't quack anyway.
> 
> So this gives our (== Matt and me) desideratum that email never raises
> (it's the Python runtime that will raise AttributeError), and also
> Oleg's (in part, anyway): an exception *will* be raised.
> 
> 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.

> 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?..

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.