python
List and document remaining significant PEPs in What's New in 3.11
As discussed with @pablogsal , meta-issue to add the significant PEPs not yet added to the summary section of the What's New in Python 3.11, as well as PEPs that are not documented in the body of the What's New but probably should be.
Specifically, the PEPs not currently mentioned in the Summary - Release Highlights section are (written with a non-canonical - so GitHub will link them):
- PEP-594 Removing dead stdlib batteries
- PEP-624 Remove Py_UNICODE encoder APIs
- PEP-657 Fine-grained error locations
- PEP-670 Macros to Functions in the C API
- PEP-678 Enriching exceptions with notes
- PEP-680: Tomllib
- PEP-681 Dataclass transforms
- PEP-682 Format specifier for signed zero (?)
These will be added to the relevant lists as appropriate, following the mold of the Python 3.10 What's New
- [x] I've opened #95916 to do so. Edit: Merged!
Most 3.11 PEPs are already described in other What's New sections, but a few are conspicuously missing and should probably be documented somewhere. I've cross referenced this with the PEP API, as well as Accepted/Final PEPs that were not tagged with a Python-Version (notably, PEP 654 was lacking it, which I also fixed):
-
[x] PEP-624 Remove Py_UNICODE encoder APIs contains an Alternative APIs section that would be useful for porting, but is not mentioned at all anywhere in What's New. Documenting the change and migration guidance was a condition of the PEP's acceptance by the SC, so it seems we should list those APIs under the
Removedsection and add the migration guidance under theC API Changes->Porting to Python 3.11subsection. ~@methane any objections if I go ahead with that, or would you like to do it yourself (I can proofread as needed)~- I went ahead and opened #96016
-
[x] PEP-654 Exception Groups and except* is listed in the Summary, but does not appear to be discussed at all in the body of the What's New, which it presumably should as it is a major new feature (and its related PEP 678 is documented under New Features, but is not listed in the Summary). ~@iritkatriel @1st1 @gvanrossum you're listed as the authors; would one of you like to write a summary, or do you want me to draft something for your (and @pablogsal 's) review?~ Done, thanks @iritkatriel !
- @iritkatriel opened as #95937
- Related: #95976
-
[ ] PEP-670 Convert Macros to Functions in the Python C API isn't mentioned anywhere; the intention with the specific PEP appears to be to avoid any backward compat impacts and be mostly transparent to users, but there is one significant change: With the limited ABI set to >=3.11, callers will need to cast arguments to their expected values. @erlend-aasland @vstinner , should at least this (and maybe a mention of the broader change) be including in C API Changes -> Porting to Python 3.11 subsection?
- On the suggestion of @erlend-aasland , I've opened #98315 to finally implement this
Then, once those are dealt with, we should finally:
- [ ] Link the relevant What's New sections and other index targets in the respective summary items, so readers can quickly jump to more information about them
Related: #95913
Regarding PEP-682 "Format specifier for signed zero", see discussion in PR #93624. Though it has a PEP, a few of us thought that it didn't warrant being in the highlights.
To note, I didn't actually add PEP 682 in #95916 unlike the others, and FWIW that reasoning seemed reasonably compelling—it didn't appear to be that much more significant from a user or developer perspective than many of the various other changes not mentioned there. I meant to bring that point up for discussion on the PR, but it seems it slipped by mind. Its up to @pablogsal , of course—if you think it should be added as a Summary bullet (its already mentioned under "Other Language Changes", along with other similarly-sized items), I would be of course happy to submit a PR to do so.
To expand on it a little, "has a PEP" may not be the right bar for appearing in highlights, since the PEP process can be triggered by subtle policy reasons, etc. and not necessarily correspond to a change of interest to a lot of people.
Right, and that's not the actual (nominal) guideline—rather, it is "most important changes", then "PEP-sized items". There isn't a rule that every PEP has to appear in the summary, nor that the summary should be composed only of PEPs. Rather, the basic idea seems to be that the section should reflect changes of the size that would generally be found in a typical PEP. This does require some degree of subjective judgement, which is left in the capable hands of the RM (hence the ping), at times aided by the change authors/committers. I didn't mean to imply this in the issue description (my earlier proposal was much more clear about that); I've revised it accordingly.
I've opened #96016 to add a description of the Py_UNICODE encoder removals for PEP 624 in the appropriate section.
Now that #95915 and #96097 are merged, I can go ahead with a PR for linking each summary entry to its appropriate subsection.
@erlend-aasland @vstinner should we include at least a short summary of the PEP 670 changes in the C API section, and/or a mention in the PEP-level summary up top? I could try to draft something, but it would probably be best if a subject matter expert like yourselves did (even as just plain text), which I could then reSTify if needed and review.
I started preparing a short text for PEP 670. I'll make it into a PR (I have some time off for this on Thursday).
Hey @erlend-aasland , did you get the chance to work on that at some point?
After talking with @erlend-aasland , I've opened #98315 to document PEP-670, which should be the last blocker before I can link all the summary items to an entry and then we can close this issue.
I'll go ahead and open a PR on the final step, linking the summary items to their sections, once #98342 is merged. Almost done here!
All tasks complete, so going ahead and closing this as resolved. Thanks everyone for your help!