Over in: * https://bugs.python.org/issue30681 * https://github.com/python/cpython/pull/22090
Georges Toth has a PR that fixes some problems with email.utils.parsedate_to_datetime(). I like the PR, and am ready to approve it for 3.10. Georges would like it back ported, which I would be normally be okay with *except* that it adds a new “defect” class. Defects are a way for the email parser to indicate problems with the incoming data without throwing an exception. This is an important constraint because we never want clients of the parser to have to deal with exceptions. So if e.g. a message had some formatting or syntactic problem, but was otherwise parseable, you’d still get an email object back from the parser, but attached to it would be a list of defects that were encountered. Clients then could choose to ignore or handle these defects depending on the use case. Defects are implemented as classes that get instantiated with some useful information and appended to an email message’s “defects” list. PR #22090 adds an InvalidDateDefect for cases where parsing the Date: header encounters problems, such as an invalid hour value. I think this is the right thing to do to fix the reported bug, but I am on the fence as to whether this new defect class should prevent back porting. OT1H, it can’t break existing code, but OTOH this defect will only be found when run in Python bug fix releases with the new defect detection. What do you think? And especially, what does Łukasz think, since he’s the RM for back port candidates 3.8 and 3.9? Cheers, -Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/ Code of Conduct: https://www.python.org/psf/codeofconduct/
