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)(). _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com