[python-committers] Re: Is adding an email package "defect" a new feature?

2020-10-26 Thread Brett Cannon 
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  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?
>
> Cheers,
> -Barry
>
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JYKOH4XXAMAUI7IXVNC2WMHQVBP5FSKC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is adding an email package "defect" a new feature?

2020-10-26 Thread Brandt Bucher 
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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/U4BLA777H2WGNU4UTJ7JJGNXENKBND26/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is adding an email package "defect" a new feature?

2020-10-26 Thread Senthil Kumaran 
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 
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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/U4BLA777H2WGNU4UTJ7JJGNXENKBND26/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SWJQYQM4MB2DC5HBG2H5WDALDMPY5ERF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is adding an email package "defect" a new feature?

2020-10-26 Thread Terry Reedy 

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 > 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/53BKYFZ5ZFH3GOLOG3VE7SNDBFFF2P54/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is adding an email package "defect" a new feature?

2020-10-26 Thread Barry Warsaw 
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  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  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?
> 
> Cheers,
> -Barry
> 
> ___
> python-committers mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2S4R3ABRS23QDAL27F7FM5ROGVKHGB76/
Code of Conduct: https://www.python.org/psf/codeofconduct/