Barry A. Warsaw added the comment:

Thanks for all the great detailed background, and the suggested approaches.  I 
think there are a couple of constraints that would be good to resolve.

* parsedate_to_datetime() is documented as "performing the same function as 
parsedate()" with an explicit difference in the good path return value, but no 
explicit difference in the bad path.  So the implication is pretty strong that 
it should return None when the date cannot be parsed.  Have a consistent API 
with parsedate() is important, and documented, so I think it's reasonable that 
the implementation should match.

* Clearly, header parsing can't raise exceptions.

* It should be easy to tell the difference between a missing Date header and a 
bogus date header.  Yes, this is an important use case.  For example, Mailman 
may do certain things when the Date header is missing (e.g. it could reject the 
message, or it could clobber the header with the server's time, etc.).  Yet if 
the header exists and is bogus, then you might want to preserve the bogus 
header for forensic or idempotency reasons.

It seems to me that the way to resolve this is to fix parsedate_to_datetime() 
so that it returns None on failure, but to add a (new) defect in 
DateHeader.parse() when that happens, e.g. InvalidDateDefect.  Then, as Tim 
suggestions and it seems like RDM agrees, that the invalid string value be used 
as the string value of the header in that case.

Thoughts?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30681>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to