Changing exception text in micro releases
This PR https://github.com/python/cpython/pull/28310 changes the message for some exceptions. Currently:
format('', '%M') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: Invalid format specifier
With the proposed change:
format('', '%M') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: Invalid format specifier '%M' for object of type 'str'
This also applies to str.format() and f-strings. This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1). Eric
On Fri, 2021-09-24 at 09:51 -0400, Eric V. Smith wrote:
This PR https://github.com/python/cpython/pull/28310 changes the message for some exceptions.
Currently:
>>> format('', '%M') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: Invalid format specifier
With the proposed change: >>> format('', '%M') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: Invalid format specifier '%M' for object of type 'str'
This also applies to str.format() and f-strings.
This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1).
Eric
People might be depending on the exception text. Tests would probably be the most relevant example. OTOH, the breakage shouldn't be that big, and probably depending on exception strings in situations like this is not great. If we are being safe, I'd probably avoid it. According to the devguide[1], micro versions are bugfixes releases, which this is not, so I'd say the patch should not be backported. However, I don't know if there is maybe another guideline or precedent. [1] https://devguide.python.org/devcycle Cheers, Filipe Laíns
On 9/24/21 6:51 AM, Eric V. Smith wrote:
This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1).
"better" != "bug fix", so I wouldn't change it in a micro release. -- ~Ethan~
On 9/24/2021 10:39 AM, Ethan Furman wrote:
On 9/24/21 6:51 AM, Eric V. Smith wrote:
This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1).
"better" != "bug fix", so I wouldn't change it in a micro release.
Yeah, as much as I'd love to see this included, you're right. Thanks for the "adult" take on it. Eric
On 9/24/2021 10:46 AM, Eric V. Smith wrote:
On 9/24/2021 10:39 AM, Ethan Furman wrote:
On 9/24/21 6:51 AM, Eric V. Smith wrote:
This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1).
"better" != "bug fix", so I wouldn't change it in a micro release.
Yeah, as much as I'd love to see this included, you're right. Thanks for the "adult" take on it.
Exception messages are subject to change in each new version, without deprecating the old version. Changes are sometimes backported when the existing message is sufficiently erroneous. 'Sufficiently' means something like 'harm of error outweighs harm of changing'. I don't think a simple, easily recognized, typo or grammar error qualifies. Among active developers, I believe Guido has the most continuity of experience with such discussions and decisions. Perhaps something could usefully be added to the devguide, but I am not sure. -- Terry Jan Reedy
In this case I am inclined not to backport. In general we should look at existing usage before making changes. Somebody’s code might break — but does it matter? That depends on a lot of factors. E.g. if parsing an error message has become a common way to get useful info out of the error that is not easily available otherwise, we have to tread lightly. —Guido On Fri, Sep 24, 2021 at 09:59 Terry Reedy <tjreedy@udel.edu> wrote:
On 9/24/2021 10:46 AM, Eric V. Smith wrote:
On 9/24/2021 10:39 AM, Ethan Furman wrote:
On 9/24/21 6:51 AM, Eric V. Smith wrote:
This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1).
"better" != "bug fix", so I wouldn't change it in a micro release.
Yeah, as much as I'd love to see this included, you're right. Thanks for the "adult" take on it.
Exception messages are subject to change in each new version, without deprecating the old version. Changes are sometimes backported when the existing message is sufficiently erroneous. 'Sufficiently' means something like 'harm of error outweighs harm of changing'. I don't think a simple, easily recognized, typo or grammar error qualifies. Among active developers, I believe Guido has the most continuity of experience with such discussions and decisions. Perhaps something could usefully be added to the devguide, but I am not sure.
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KKZVPESK... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
On 9/24/2021 4:53 PM, Guido van Rossum wrote:
In this case I am inclined not to backport. I agree. I decided not to backport it. In general we should look at existing usage before making changes. Somebody’s code might break — but does it matter? That depends on a lot of factors. E.g. if parsing an error message has become a common way to get useful info out of the error that is not easily available otherwise, we have to tread lightly.
In this case I don't think anyone could be parsing it, because the existing version doesn't contain any information, it's always the string "Invalid format specifier". But I agree we should be cautious, so this will wait until 3.11. The original bug was reported 7.5 years ago, so it's not like we're in any rush. Thanks for the input. Eric
—Guido
On Fri, Sep 24, 2021 at 09:59 Terry Reedy <tjreedy@udel.edu <mailto:tjreedy@udel.edu>> wrote:
On 9/24/2021 10:46 AM, Eric V. Smith wrote: > On 9/24/2021 10:39 AM, Ethan Furman wrote: >> On 9/24/21 6:51 AM, Eric V. Smith wrote: >> >> >> > This is clearly an improvement. My question is: is it okay to >> backport this to 3.9 and 3.10? I >> > think we have a rule that it's okay to change the exception text, >> but I'm not sure how that >> > applies to micro releases (3.9.x, 3.10.1). >> >> "better" != "bug fix", so I wouldn't change it in a micro release. > > Yeah, as much as I'd love to see this included, you're right. Thanks for > the "adult" take on it.
Exception messages are subject to change in each new version, without deprecating the old version. Changes are sometimes backported when the existing message is sufficiently erroneous. 'Sufficiently' means something like 'harm of error outweighs harm of changing'. I don't think a simple, easily recognized, typo or grammar error qualifies. Among active developers, I believe Guido has the most continuity of experience with such discussions and decisions. Perhaps something could usefully be added to the devguide, but I am not sure.
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org> To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KKZVPESK... <https://mail.python.org/archives/list/python-dev@python.org/message/KKZVPESK...> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
-- --Guido (mobile)
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GQWMP7BL... Code of Conduct: http://python.org/psf/codeofconduct/
24.09.21 16:51, Eric V. Smith пише:
This is clearly an improvement. My question is: is it okay to backport this to 3.9 and 3.10? I think we have a rule that it's okay to change the exception text, but I'm not sure how that applies to micro releases (3.9.x, 3.10.1).
I am sure that it will break someone's tests. Since the current error message is not wrong, it is not a bug fix. If you want it very much you can discuss backporting to 3.10.1 with Pablo. Few people will upgrade immediately after releasing 3.10.0, and for others this change will be a part of upgrading to 3.10. But 3.9 is mature enough for now.
participants (6)
-
Eric V. Smith -
Ethan Furman -
Filipe Laíns -
Guido van Rossum -
Serhiy Storchaka -
Terry Reedy