Is adding an email package "defect" a new feature?
Over in:
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
Our lesson from our "innocuous" addition of booleans makes me leery of anything that tweaks the API such that it isn't compatible in the same feature release.
On Fri, Oct 23, 2020 at 3:16 PM Barry Warsaw <barry@python.org> wrote:
Over in:
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
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/R... Code of Conduct: https://www.python.org/psf/codeofconduct/
Brett Cannon wrote:
Our lesson from our "innocuous" addition of booleans makes me leery of anything that tweaks the API such that it isn't compatible in the same feature release.
Agreed. I'm not 100% sure of the context, but were a few typing module additions a while back that made CI a bit of a pain (needing to pin some jobs to specific CPython bugfix releases, which isn't trivial to do across providers and platforms).
This can probably just be "another reason why 3.10 is better than 3.9", right?
I had formed my opinion at Barry's email very early. I favor not backporting too. This is a new class and we cannot control people expectations. We are going to have yearly release cycles that is another reason not to backport this, and only move forward.
On Mon, Oct 26, 2020 at 12:34 PM Brandt Bucher <brandtbucher@gmail.com> wrote:
Brett Cannon wrote:
Our lesson from our "innocuous" addition of booleans makes me leery of anything that tweaks the API such that it isn't compatible in the same feature release.
Agreed. I'm not 100% sure of the context, but were a few typing module additions a while back that made CI a bit of a pain (needing to pin some jobs to specific CPython bugfix releases, which isn't trivial to do across providers and platforms).
This can probably just be "another reason why 3.10 is better than 3.9", right?
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/U... Code of Conduct: https://www.python.org/psf/codeofconduct/
On 10/26/2020 3:09 PM, Brett Cannon wrote:
Our lesson from our "innocuous" addition of booleans makes me leery of anything that tweaks the API such that it isn't compatible in the same feature release.
There were other instances, such as a undocumented io change related to stream position (I believe in 3.1) that broke existing code. We then reinforced the existing policy of no new features in bugfix releases (except in exceptional modules). The principle is that Python x.y is a version of Python documented in the Python x.y docs. Changes and additions to x.y versions are noted.
The addition of a new 'defect' class would make 3.9.1 a microversion of Python, and the addition would have to be noted. Any code that uses it would have to be marked as requiring not just 3.9 but 3.9.1+. Brandt noted problems with CI and buildbots.
One of the very rare x.y.z change notes is in https://docs.python.org/2.7/library/difflib.html#difflib.SequenceMatcher "New in version 2.7.1: The autojunk parameter."
I added this in consultation with Tim Peters only after thorough discussion *and approval* from coredevs on, as I remember, pydev. The justification was that there was a) a severe usage bug that affected multiple people, leading to 4 duplicate bpo reports plus additional 'me-to's from others and b) no way to fix it without getting optional additional information from users.
So I think a backport of a new class needs similar discussion and approval either by consensus or SC.
On Fri, Oct 23, 2020 at 3:16 PM Barry Warsaw <barry@python.org <mailto:barry@python.org>> wrote:
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?
True/False in 2.2.1 still hurts!
Thanks all for confirming my intuition. I will not back port this change.
-Barry
On Oct 26, 2020, at 12:09, Brett Cannon <brett@python.org> wrote:
Our lesson from our "innocuous" addition of booleans makes me leery of anything that tweaks the API such that it isn't compatible in the same feature release.
On Fri, Oct 23, 2020 at 3:16 PM Barry Warsaw <barry@python.org> wrote: Over in:
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
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/R... Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (5)
-
Barry Warsaw
-
Brandt Bucher
-
Brett Cannon
-
Senthil Kumaran
-
Terry Reedy