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 <tjre...@udel.edu
<mailto:tjre...@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-le...@python.org
<mailto:python-dev-le...@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/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/
<https://mail.python.org/archives/list/python-dev@python.org/message/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/>
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-le...@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/GQWMP7BL5AJH3ZAEU22LPZLO4R4OW6RY/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/QARFSFOLDLKOOIURMM7V2MKXXVH5ICSI/
Code of Conduct: http://python.org/psf/codeofconduct/
