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 <ba...@python.org
<mailto:ba...@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?
_______________________________________________
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/53BKYFZ5ZFH3GOLOG3VE7SNDBFFF2P54/
Code of Conduct: https://www.python.org/psf/codeofconduct/
