List and document remaining significant PEPs in What's New in 3.11 #95914
Comments
…s New (pythonGH-95916) (cherry picked from commit 6376433) Co-authored-by: CAM Gerlach <[email protected]>
…H-95916) (GH-95927) (cherry picked from commit 6376433) Co-authored-by: CAM Gerlach <[email protected]>
|
I'll add something. on PEP 654. |
|
Thanks @iritkatriel ! |
…ew in 3.11' (pythonGH-95937) (cherry picked from commit 1402d2c) Co-authored-by: Irit Katriel <[email protected]>
|
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. |
CAM-Gerlach
changed the title
|
I've opened #96016 to add a description of the |
…s New (#96016) * 3.11 Whatsnew: Add Py_UNICODE encode functions removed in PEP 624 * Just use :func: instead of :c:func: for non-resolved funcs so ! works
… What's New (pythonGH-96016) * 3.11 Whatsnew: Add Py_UNICODE encode functions removed in PEP 624 * Just use :func: instead of :c:func: for non-resolved funcs so ! works (cherry picked from commit b6d88b7) Co-authored-by: C.A.M. Gerlach <[email protected]>
…s New (GH-96016) * 3.11 Whatsnew: Add Py_UNICODE encode functions removed in PEP 624 * Just use :func: instead of :c:func: for non-resolved funcs so ! works (cherry picked from commit b6d88b7) Co-authored-by: C.A.M. Gerlach <[email protected]>
…3.11' (GH-95937) (cherry picked from commit 1402d2c) Co-authored-by: Irit Katriel <[email protected]>
|
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. |
…nGH-98315) (cherry picked from commit aafc53c) Co-authored-by: C.A.M. Gerlach <[email protected]>
(cherry picked from commit aafc53c) Co-authored-by: C.A.M. Gerlach <[email protected]>
* main: (31 commits) pythongh-95913: Move subinterpreter exper removal to 3.11 WhatsNew (pythonGH-98345) pythongh-95914: Add What's New item describing PEP 670 changes (python#98315) Remove unused arrange_output_buffer function from zlibmodule.c. (pythonGH-98358) pythongh-98174: Handle EPROTOTYPE under macOS in test_sendfile_fallback_close_peer_in_the_middle_of_receiving (python#98316) pythonGH-98327: Reduce scope of catch_warnings() in _make_subprocess_transport (python#98333) pythongh-93691: Compiler's code-gen passes location around instead of holding it on the global compiler state (pythonGH-98001) pythongh-97669: Create Tools/build/ directory (python#97963) pythongh-95534: Improve gzip reading speed by 10% (python#97664) pythongh-95913: Forward-port int/str security change to 3.11 What's New in main (python#98344) pythonGH-91415: Mention alphabetical sort ordering in the Sorting HOWTO (pythonGH-98336) pythongh-97930: Merge with importlib_resources 5.9 (pythonGH-97929) pythongh-85525: Remove extra row in doc (python#98337) pythongh-85299: Add note warning about entry point guard for asyncio example (python#93457) pythongh-97527: IDLE - fix buggy macosx patch (python#98313) pythongh-98307: Add docstring and documentation for SysLogHandler.createSocket (pythonGH-98319) pythongh-94808: Cover `PyFunction_GetCode`, `PyFunction_GetGlobals`, `PyFunction_GetModule` (python#98158) pythonGH-94597: Deprecate child watcher getters and setters (python#98215) pythongh-98254: Include stdlib module names in error messages for NameErrors (python#98255) Improve speed. Reduce auxiliary memory to 16.6% of the main array. (pythonGH-98294) [doc] Update logging cookbook with an example of custom handling of levels. (pythonGH-98290) ...
|
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! |
Add links to Summary items to where readers can learn more
) Add links to Summary items to where readers can learn more (cherry picked from commit fcae195) Co-authored-by: C.A.M. Gerlach <[email protected]>
Add links to Summary items to where readers can learn more (cherry picked from commit fcae195) Co-authored-by: C.A.M. Gerlach <[email protected]>
|
All tasks complete, so going ahead and closing this as resolved. Thanks everyone for your help! |
|
Great job! |
(cherry picked from commit aafc53c) Co-authored-by: C.A.M. Gerlach <[email protected]>
Add links to Summary items to where readers can learn more (cherry picked from commit fcae195) Co-authored-by: C.A.M. Gerlach <[email protected]>
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):These will be added to the relevant lists as appropriate, following the mold of the Python 3.10 What's New
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):
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)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 !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?
Then, once those are dealt with, we should finally:
Related: #95913
The text was updated successfully, but these errors were encountered: