[Python-Dev] Changing exception text in micro releases

[Eric V. Smith]

This PR https://github.com/python/cpython/pull/28310 changes the message 
for some exceptions.


Currently:

>>> format('', '%M')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Invalid format specifier

With the proposed change:
>>> format('', '%M')
Traceback (most recent call last):
  File "", line 1, in 
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

___
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/G6H3M7USSQ2YCFMATMU24J5BJMDJPDVW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP-646 question: unpacking into single Generic parameter

[willi]

Hello,

first of all, thanks for working on variadic generics! I look forward to them.

My question: all the examples in https://www.python.org/dev/peps/pep-0646/ 
unpack into variadic arguments. But can I write code like this?

```
Ts = TypeVarTuple("Ts")

def enumerate_args(f: Callable[[*Tuple[int, Ts]]], *args: *Ts):
f(*enumerate(args))
```

In particular I'm talking about the `*Tuple[int, Ts]` syntax. All the examples 
from the PEP use `*Ts` so I don't know if this is legal, but I hope so.

This should probably be clarified in the PEP.

-- 
Best regards,

Willi Schinmeyer
___
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/K76H6C5JWGJ7TW6DGOCZGOTVONWOFCWD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing exception text in micro releases

[Filipe Laíns]

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 "", line 1, in 
> ValueError: Invalid format specifier
> 
> With the proposed change:
>  >>> format('', '%M')
> Traceback (most recent call last):
>    File "", line 1, in 
> 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


signature.asc
Description: This is a digitally signed message part
___
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/W2LQZ44GERUVGNNQOD6UJKK3LRPYBOAP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing exception text in micro releases

[Ethan Furman]

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~
___
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/G3EVFK5K3REHNMYYAC2XLBALOUICIDLN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing exception text in micro releases

[Eric V. Smith]

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


___
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/SXIUK2DELUVAUESWLUYJBUA6IVYBTX2C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing exception text in micro releases

[Terry Reedy]

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-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/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-09-17 - 2021-09-24)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7333 (-48)
  closed 49684 (+97)
  total  57017 (+49)

Open issues with patches: 2907 


Issues opened (37)
==

#34451: docs: tutorial/introduction doesn't mention toggle of prompts
https://bugs.python.org/issue34451  reopened by rhettinger

#45237: Python subprocess not honoring append mode for stdout on Windo
https://bugs.python.org/issue45237  opened by wolfgang-kuehn

#45239: email.utils.parsedate_tz raises UnboundLocalError if time has 
https://bugs.python.org/issue45239  opened by benhoyt

#45240: Add +REPORT_NDIFF option to pdb tests that use doctest
https://bugs.python.org/issue45240  opened by andrei.avk

#45242: test_pdb fails
https://bugs.python.org/issue45242  opened by oliphaunt

#45243: [sqlite3] add support for changing connection limits
https://bugs.python.org/issue45243  opened by erlendaasland

#45244: pip not installed with fresh python3.8.10 installation
https://bugs.python.org/issue45244  opened by shreyanse081

#45247: Add explicit support for Cython to the C API.
https://bugs.python.org/issue45247  opened by Mark.Shannon

#45249: SyntaxError location range indicator does not work in doctests
https://bugs.python.org/issue45249  opened by andrei.avk

#45250: Make sure documentation is accurate for what an (async) iterab
https://bugs.python.org/issue45250  opened by brett.cannon

#45251: signal.SIGCLD alias is not available on OSX
https://bugs.python.org/issue45251  opened by tcaswell

#45252: Missing support for Source Specific Multicast
https://bugs.python.org/issue45252  opened by ciresnave

#45253: mimetypes cannot detect mime of mka files
https://bugs.python.org/issue45253  opened by manujchandra

#45254: HAS_SHMEM detection logic is duplicated in implementation and 
https://bugs.python.org/issue45254  opened by sobolevn

#45255: sqlite3.connect() should check if the sqlite file exists and t
https://bugs.python.org/issue45255  opened by iboates

#45256: Remove the usage of the C stack in Python to Python calls
https://bugs.python.org/issue45256  opened by pablogsal

#45258: sysroot_paths in setup.py does not consider -isysroot for macO
https://bugs.python.org/issue45258  opened by isuruf

#45260: Implement superinstruction UNPACK_SEQUENCE_ST
https://bugs.python.org/issue45260  opened by zhangchaospecial

#45261: Unreliable (?) results from timeit (cache issue?)
https://bugs.python.org/issue45261  opened by timholy

#45262: crash if asyncio is used before and after re-initialization if
https://bugs.python.org/issue45262  opened by benjamin-sch

#45264: venv: Make activate et al. export custom prompt prefix as an e
https://bugs.python.org/issue45264  opened by jwodder

#45266: subtype_clear can not be called from derived types
https://bugs.python.org/issue45266  opened by Victor Milovanov

#45267: New install Python 3.9.7 install of Sphinx Document Generator 
https://bugs.python.org/issue45267  opened by pbroe

#45269: c_make_encoder() has uncovered error: "argument 1 must be dict
https://bugs.python.org/issue45269  opened by sobolevn

#45272: 'os.path' should not be a frozen module
https://bugs.python.org/issue45272  opened by steve.dower

#45273: OS-specific frozen modules are built, even on other OSes.
https://bugs.python.org/issue45273  opened by eric.snow

#45274: Race condition in Thread._wait_for_tstate_lock()
https://bugs.python.org/issue45274  opened by vstinner

#45275: Make argparse print description of subcommand when invoke help
https://bugs.python.org/issue45275  opened by longendu

#45276: avoid try 1000 in asyncio all_tasks by making weak collection 
https://bugs.python.org/issue45276  opened by graingert

#45277: typo in codecs documentation
https://bugs.python.org/issue45277  opened by Gronahak

#45278: RuntimeError on race on weakset concurrent iteration
https://bugs.python.org/issue45278  opened by bjs

#45279: avoid redundant _commit_removals pending_removals guard
https://bugs.python.org/issue45279  opened by graingert

#45280: Empty typing.NamedTuple creation is not tested
https://bugs.python.org/issue45280  opened by sobolevn

#45281: Make `is_attribute` and `module` arguments to `ForwardRef` kw-
https://bugs.python.org/issue45281  opened by sobolevn

#45282: isinstance(x, typing.Protocol-class) unexpectedly evaluates pr
https://bugs.python.org/issue45282  opened by daitakahashi

#45283: Top / function argument level ClassVar should not be allowed d
https://bugs.python.org/issue45283  opened by sobolevn

#45284: Better `TypeError` message when a string is indexed using a no
https://bugs.python.org/issue45284  opened by Rin



Most recent 15 issues with no replies (15)
==

#45283: Top / function argument level ClassVar should not be allowed d
https://bugs.python.org/issue45283

#4

[Python-Dev] Re: Changing exception text in micro releases

[Guido van Rossum]

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  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-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/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/
> Code of Conduct: 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] Re: Changing exception text in micro releases

[Eric V. Smith]

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 > 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-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/KKZVPESKEAIL4DYEIGSTPLKE34KH7XTQ/


Code of Conduct: 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/

[Python-Dev] Accepting PEP 654.

[Thomas Wouters]

Irit, Guido, Yuri, Nathaniel,

(In the interest of visibility, this was also posted to discuss.python.org

.)

After careful consideration and rather lengthy discussion, the Steering
Council has decided to accept PEP 654 (Exception Groups and except*)
. We do have two requests, one
of which we mentioned before. We’re very pleased with the amount of care
and discussion that went into this PEP, and we’re satisfied that it solves
a real-world problem in the least disruptive way. We do remain open for
further tweaking of the design, incorporating some of Nathaniel’s ideas, or
new ones, but we want to move forward with PEP 654’s proposal and let
people get hands-on experience with it. To that end, our request is that we
get at least one non-toy use of ExceptionGroups somewhere in the standard
library (targeted to 3.11, like PEP 654), and preferably get some
third-party experimentation with it as well. The other request is that PEP
654 be updated with a reference to Nathaniel’s ideas (a link to the
Discourse discussion), outlining why PEP 654 rejects those ideas (it could
just be a copy-paste of some of the discussion, just so long as it’s
recorded in the PEP).

Regarding Nathaniel’s alternative proposal
,
I want to be clear on the main reason why we’re accepting PEP 654 rather
than waiting for a more complete alternative PEP with concrete examples.
The SC agrees that exception groups solve a real problem, albeit a
relatively rare and low-level one. We don’t think the problem it solves is
big enough that it warrants fundamental changes to the language; changes
that would affect the way everyone would write code, or that would make
learning Python or reasoning about Python code harder. PEP 654 just about
squeaks by those criteria: the new syntax is something new to learn about
Python, but it’s not something that’s *required *unless consuming an API
that uses ExceptionGroups. ExceptionGroups behave like regular exceptions
in code that does not expect them, and do not change the behaviour of
existing try/except. In code that potentially produces ExceptionGroups (or
its documentation, examples, tutorials, etc) there is enough opportunity to
document that, show examples of how to use it, explain the implications and
refer to documentation about the concept of ExceptionGroups.

By contrast, Nathaniel’s proposal that ExceptionGroups affect how *existing
*try/except statements behave, fails those criteria. By sheer nature of
doing something meaningful (if confusing) in try/except, it would encourage
API designs that let ExceptionGroups escape to unsuspecting code. It would
introduce subtle bugs in code that -- entirely legitimately -- expects only
one except block to be executed, or only executed once. These problems
would be very hard to detect since they would only show up if called code
could *in practice* raise ExceptionGroups. We don’t consider this a viable
design choice.

The SC does remain open to proposals to extend PEP 654 (like adding an API
to iterate over ExceptionGroups), or change some of the semantics (like
flat versus nested ExceptionGroups), and we do not want to discourage
discussion on any of this. We do want to move forward with PEP 654 as-is in
the meantime, in particular to get practical experience in the standard
library.

With thanks for all your hard work,
For the whole SC,
Thomas.
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/2ORDAW74LGE3ZI2QETPJRT2ZL7MCCPG2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 654.

[Thomas Wouters]

On Sat, Sep 25, 2021 at 12:06 AM Thomas Wouters  wrote:

>
> Irit, Guido, Yuri, Nathaniel,
>

I do apologise for the typo in your name, Yury... somehow none of us caught
it in our proofreading of the response :( I fixed it on Discourse with an
edit, but email, alas...

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/SG5BKKB5CYUBFTJA35AGW46IFLSHNMG4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 654.

[Yury Selivanov]

Ah, that's no problem, both spellings are good. Since I'm replying on
Pyhton-dev, I'll quote my Discord response here:

"Thank you Thomas and the SC. I’ll start working on incorporating
TaskGroups into asyncio in the next few weeks."

Thanks,
Yury


On Fri, Sep 24, 2021 at 3:13 PM, Thomas Wouters  wrote:

> On Sat, Sep 25, 2021 at 12:06 AM Thomas Wouters  wrote:
>
>
> Irit, Guido, Yuri, Nathaniel,
>
>
> I do apologise for the typo in your name, Yury... somehow none of us
> caught it in our proofreading of the response :( I fixed it on Discourse
> with an edit, but email, alas...
>
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
>
___
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/CQQNVGRPL7JJSNAHM3CNSUZUDDLSCIWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-646 question: unpacking into single Generic parameter

[Mehdi2277]

I don't believe this is supported in pep 646 today. It was originally going to 
be supported with a Map operator. With a Map operator it would let you do 
something like,

T = TypeVar('T')
Ts = TypeVarTuple("Ts")
IndexedTuple = Tuple[Int, T]

def enumerage_args(*args: *Ts) -> *Map[IndexedTuple, Ts]
  return enumerate(args)

Map operator takes two arguments, a generic type and type var tuple. This 
document describes map operator in more detail and an older version of the pep 
had it.

https://docs.google.com/document/d/1szTVcFyLznoDT7phtT-6Fpvp27XaBw9DmbTLHrB6BE4/edit

The reason it is missing is original version of 646 was becoming too complex 
for a single pep. My understanding is your example/similar examples are 
intended for the future to be supported, but that Map operator and other 
extensions to variadic generics will be future peps.
___
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/YBJXIAGODKH4NB5OD4YBZUZPA7NV6T73/
Code of Conduct: http://python.org/psf/codeofconduct/