[Email-SIG] API thoughts

[Steffen Daode Nurpmeso]

On Wed, Mar 02, 2011 at 07:50:20PM -0500, R. David Murray wrote:
> That is, if the defects list is non-empty,
> the message is technically malformed.  Of course, that information by
> itself isn't necessarily useful, which is why defects is a list
> of defects.
> "is_processable" lies in the eyes of the application.
> What defects is it capable of dealing with?  The email package
> can't know that.  So, again, that's why defects is a list.
> 
> Let me clarify what I mean by the policy controlling "what, exactly, is
> a defect".  The idea here is that when parsing an email, each deviance
> from the RFCs counts as a defect (the current email package, by the way,
> only detects a small number of such defects!).  But when parsing, say,
> an http stream, non-ascii characters in headers are perfectly legal.
> So it seems to make sense that the HTTP policy would change what counts
> as a defect during the operation of the parser.

So i would hope for '.all_defects[]' and (policy-adjusted) 
'.defects[]'.  I would hope for 
'.had_header_defects(policy_only=True)', 
'.had_payload_defects(policy_only=True)'.

Doing so would fill the huge hole in between 'not len(defects)' 
and the detailed inspection of a defects list which consists of 
a highly differentiated tree of classes.

The parser has to parse- and does encounter all of these anyway, 
and an application cannot re-collect this (dropped) information 
except with expensive effort, i.e. at least choosing a different, 
stricter policy followed by another parse of the bogus mail.

In the end it is my believe that a framework should bring light 
onto all aspects of a thing, such that no other framework is ever 
needed, but especially not on a lower level (except the framework 
is so designed that it allows replacement of its own low-level 
interface, say). 
And i don't think there can be a higher level interface than 
message_from_(bytes|string)().