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?

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?