Mailman 3 September 2020 - Python-Dev

[RELEASE] Python 3.9.0rc2 is now available for testing
by Łukasz Langa Sept. 17, 2020

Sept. 17, 2020

Python 3.9.0 is almost ready. This release, 3.9.0rc2, is the last planned preview before the final release of Python 3.9.0 on 2020-10-05. Get it here: https://www.python.org/downloads/release/python-390rc2/ <https://www.python.org/downloads/release/python-390rc2/> In the mean time, we strongly encourage maintainers of third-party Python projects to prepare their projects for 3.9 compatibility during this phase. As always, report any issues to the Python bug tracker <https://bugs.… [View More]

1 0

Python 4 FAQ
by Steven D'Aprano Sept. 16, 2020

Sept. 16, 2020

There's still a lot of community angst over the possibility that some hypothetical Python 4 will be like the 2/3 transition. Some people even imagine that the version after 3.9 could be that transition. I know we're not responsible for the ravings of people on social media, but do you think we should do a FAQ? Something along the lines of: - the version after 3.9 will be 3.10, and in fact it already exists; - if there ever is a version 4, the transition from 3 to 4 will be more like that … [View More]

4 3

docs: I'd like new features to references their PEPs
by Cameron Simpson Sept. 16, 2020

Sept. 16, 2020

So, today I noticed __length_hint__, and then operator.length_hint. Neither mentions its design purpose, only its specification. And while that is minimally enough, knowing the purpoe (size estimation for use by presized allocation operations) lets an implementor write something more appropriate. While it'd be nice to have a short sentence with the provoking rationale for the feature in the docs, it would also be nice to reference the PEP. As a concrete example, for __length_hint__ and … [View More]

4 7

Python-checkins mailing list broken?
by Jeremy Kloth Sept. 14, 2020

Sept. 14, 2020

It seems that python-checkins isn't receiving any new commits since the 8th of September. A quick check of the github page shows activity since then, as do the buildbots. Just a heads up. -- Jeremy Kloth

3 2

Re: docs: I'd like new features to references their PEPs
by David Antonini Sept. 14, 2020

Sept. 14, 2020

If the API has changed significantly since the PEP, simply stating that could be useful eg "as originally specified in `PEP x`, although the API and typical usage have evolved since originally implemented". Or "as orginally specified in `PEP x`, although that API was later changed because `insert terrible namespace clash or other reoganisation`. This would inform readers that information/code snippets found elsewhere might be targeting various degrees of different API/usages. The PEP link/this … [View More]detail could be in a superscript linkPEP or note2 that appears upon mouseover, or similarly obscured to minimise reading interruption, if such explanation is considered useful, but breaks the flow of the doc more than desirable. I feel like the Docs Working Group might have some productive discussion on such topics, when it gets started. [Google IT Support Professional Certificate]<https://www.youracclaim.com/badges/95b4438c-8719-4e89-ad79-6c45c3c8481f/pub…> [Google IT Automation with Python Professional Certificate] <https://www.youracclaim.com/badges/75926d2a-6313-4c43-9f76-82bc8a3ed4b0/pub…> ________________________________ From: python-dev-request(a)python.org <python-dev-request(a)python.org> Sent: Monday, September 14, 2020 11:00 AM To: python-dev(a)python.org <python-dev(a)python.org> Subject: Python-Dev Digest, Vol 206, Issue 24 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman3/lists/python-dev.python.org/ or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. docs: I'd like new features to references their PEPs (Cameron Simpson) 2. Re: docs: I'd like new features to references their PEPs (Guido van Rossum) 3. Re: docs: I'd like new features to references their PEPs (Cameron Simpson) 4. Re: docs: I'd like new features to references their PEPs (Ned Deily) 5. Re: docs: I'd like new features to references their PEPs (Cameron Simpson) ---------------------------------------------------------------------- Date: Mon, 14 Sep 2020 12:50:24 +1000 From: Cameron Simpson <cs(a)cskk.id.au> Subject: [Python-Dev] docs: I'd like new features to references their PEPs To: Python-Dev <python-dev(a)python.org> Message-ID: <20200914025024.GA69157(a)cskk.homeip.net> Content-Type: text/plain; charset=us-ascii Message: 1 So, today I noticed __length_hint__, and then operator.length_hint. Neither mentions its design purpose, only its specification. And while that is minimally enough, knowing the purpoe (size estimation for use by presized allocation operations) lets an implementor write something more appropriate. While it'd be nice to have a short sentence with the provoking rationale for the feature in the docs, it would also be nice to reference the PEP. As a concrete example, for __length_hint__ and operator.length_hint, I wish that in addition to saying "New in version 3.4", it also said "specified by PEP424 [link]", since I had to go find that with a search engine to understand the rationale. Would PRs with such patches be welcome? Cheers, Cameron Simpson <cs(a)cskk.id.au> ------------------------------ Date: Sun, 13 Sep 2020 20:51:19 -0700 From: Guido van Rossum <guido(a)python.org> Subject: [Python-Dev] Re: docs: I'd like new features to references their PEPs To: Cameron Simpson <cs(a)cskk.id.au> Cc: Python-Dev <python-dev(a)python.org> Message-ID: <CAP7+vJJFSRdSpbHks3r6xvB4P3+OXoMRu9gSwiMdFDVCekVWyw(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000006ee04305af3df322" Message: 2 --0000000000006ee04305af3df322 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 13, 2020 at 8:12 PM Cameron Simpson <cs(a)cskk.id.au> wrote: > So, today I noticed __length_hint__, and then operator.length_hint. > Neither mentions its design purpose, only its specification. And while > that is minimally enough, knowing the purpoe (size estimation for use by > presized allocation operations) lets an implementor write something more > appropriate. > > While it'd be nice to have a short sentence with the provoking rationale > for the feature in the docs, it would also be nice to reference the PEP. > > As a concrete example, for __length_hint__ and operator.length_hint, I > wish that in addition to saying "New in version 3.4", it also said > "specified by PEP424 [link]", since I had to go find that with a search > engine to understand the rationale. > > Would PRs with such patches be welcome? > Yeah, I think that's a reasonable idea, and I don't think it needs a news item or bpo bug either. If you know there's a PEP you should be able to find it through the what's new doc for the version where the feature was added (assuming there's a "versionadded" note), but that's pretty indirect, and people might not even think there could be a PEP. A downside of linking to the PEP is that sometimes the PEP has an outdated version of an API. For example asyncio has evolved quite a bit since PEP 3156 (some stuff in the PEP turned out not so hot), and I'm sure that's not the only case. But all in all I like the idea of linking to the PEP from the "versionadded" or "versionchanged" note. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> --0000000000006ee04305af3df322 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Sun, Sep 13, 2020 at 8:12 PM Cameron Simpson <<a href=3D"mailt= o:cs@cskk.id.au">cs(a)cskk.id.au</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex">So, today I noticed __length_hint__, and then= operator.length_hint.=C2=A0 <br> Neither mentions its design purpose, only its specification. And while <br> that is minimally enough, knowing the purpoe (size estimation for use by <b= r> presized allocation operations) lets an implementor write something more <b= r> appropriate.<br> <br> While it'd be nice to have a short sentence with the provoking rational= e <br> for the feature in the docs, it would also be nice to reference the PEP.<br= > <br> As a concrete example, for __length_hint__ and operator.length_hint, I <br> wish that in addition to saying "New in version 3.4", it also sai= d <br> "specified by PEP424 [link]", since I had to go find that with a = search <br> engine to understand the rationale.<br> <br> Would PRs with such patches be welcome?<br></blockquote><div><br></div><div= >Yeah, I think that's a reasonable idea, and I don't think it needs= a news item or bpo bug either. If you know there's a PEP you should be= able to find it through the what's new doc for the version where the f= eature was added (assuming there's a "versionadded" note), bu= t that's pretty indirect, and people might not even think there could b= e a PEP.</div><div><br></div><div>A downside of linking to the PEP is that = sometimes the PEP has an outdated version of an API. For example asyncio ha= s evolved quite a bit since PEP 3156 (some stuff in the PEP turned out not = so hot), and I'm sure that's not the only case. But all in all I li= ke the idea of linking to the PEP from the "versionadded" or &quo= t;versionchanged" note.<br></div></div><br>-- <br><div dir=3D"ltr" cla= ss=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--Guido = van Rossum (<a href=3D"http://python.org/~guido" target=3D"_blank">python.o= rg/~guido</a>)</div><div><i style=3D"font-family:Arial,Helvetica,sans-serif= ;font-size:small;font-weight:400;letter-spacing:normal;text-align:start;tex= t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgr= ound-color:rgb(255,255,255);color:rgb(136,136,136)"><span>Pronouns</span>: = he/him </i><a href=3D"http://feministing.com/2015/02/03/how-using-they-as-a= -singular-pronoun-can-change-the-world/" style=3D"color:rgb(17,85,204);font= -family:Arial,Helvetica,sans-serif;font-size:small;font-style:normal;font-w= eight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-trans= form:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,= 255)" target=3D"_blank"><i>(why is my=C2=A0<span>pronoun</span>=C2=A0here?)= </i></a></div></div></div></div></div></div> --0000000000006ee04305af3df322-- ------------------------------ Date: Mon, 14 Sep 2020 15:07:31 +1000 From: Cameron Simpson <cs(a)cskk.id.au> Subject: [Python-Dev] Re: docs: I'd like new features to references their PEPs To: Guido van Rossum <guido(a)python.org> Cc: Python-Dev <python-dev(a)python.org> Message-ID: <20200914050731.GA45157(a)cskk.homeip.net> Content-Type: text/plain; charset=us-ascii Message: 3 On 13Sep2020 20:51, Guido van Rossum <guido(a)python.org> wrote: >On Sun, Sep 13, 2020 at 8:12 PM Cameron Simpson <cs(a)cskk.id.au> wrote: >> As a concrete example, for __length_hint__ and operator.length_hint, >> I >> wish that in addition to saying "New in version 3.4", it also said >> "specified by PEP424 [link]", since I had to go find that with a search >> engine to understand the rationale. [...] >A downside of linking to the PEP is that sometimes the PEP has an >outdated >version of an API. For example asyncio has evolved quite a bit since PEP >3156 (some stuff in the PEP turned out not so hot), and I'm sure that's not >the only case. But all in all I like the idea of linking to the PEP from >the "versionadded" or "versionchanged" note. Happy to use the term "originally specified by PEP424 [link]" :-) I'll make some PRs. How to submit? Here, or a BPO or something? Cheers, Cameron Simpson <cs(a)cskk.id.au> ------------------------------ Date: Mon, 14 Sep 2020 01:16:00 -0400 From: Ned Deily <nad(a)python.org> Subject: [Python-Dev] Re: docs: I'd like new features to references their PEPs To: Cameron Simpson <cs(a)cskk.id.au> Cc: Python-Dev <python-dev(a)python.org> Message-ID: <CCD5D596-44EB-41F5-91F6-15BF1A066822(a)python.org> Content-Type: text/plain; charset=us-ascii Message: 4 On Sep 14, 2020, at 01:07, Cameron Simpson <cs(a)cskk.id.au> wrote: > On 13Sep2020 20:51, Guido van Rossum <guido(a)python.org> wrote: >> On Sun, Sep 13, 2020 at 8:12 PM Cameron Simpson <cs(a)cskk.id.au> wrote: >>> As a concrete example, for __length_hint__ and operator.length_hint, >>> I >>> wish that in addition to saying "New in version 3.4", it also said >>> "specified by PEP424 [link]", since I had to go find that with a search >>> engine to understand the rationale. > [...] >> A downside of linking to the PEP is that sometimes the PEP has an >> outdated >> version of an API. For example asyncio has evolved quite a bit since PEP >> 3156 (some stuff in the PEP turned out not so hot), and I'm sure that's not >> the only case. But all in all I like the idea of linking to the PEP from >> the "versionadded" or "versionchanged" note. > Happy to use the term "originally specified by PEP424 [link]" :-) > > I'll make some PRs. How to submit? Here, or a BPO or something? My suggestion would be to open one BPO issue for "adding PEP references to documentation" and then creating PRs as needed against it. As you probably know, the devguide has the details including for the inline markup role :pep:. https://devguide.python.org/documenting/#rest-inline-markup -- Ned Deily nad(a)python.org -- [] ------------------------------ Date: Mon, 14 Sep 2020 19:25:57 +1000 From: Cameron Simpson <cs(a)cskk.id.au> Subject: [Python-Dev] Re: docs: I'd like new features to references their PEPs To: Ned Deily <nad(a)python.org> Cc: Python-Dev <python-dev(a)python.org> Message-ID: <20200914092557.GA40543(a)cskk.homeip.net> Content-Type: text/plain; charset=us-ascii Message: 5 On 14Sep2020 01:16, Ned Deily <nad(a)python.org> wrote: >> I'll make some PRs. How to submit? Here, or a BPO or something? > >My suggestion would be to open one BPO issue for "adding PEP references to documentation" and then creating PRs as needed against it. As you probably know, the devguide has the details including for the inline markup role :pep:. > >https://devguide.python.org/documenting/#rest-inline-markup Thanks Ned. - Cameron Simpson <cs(a)cskk.id.au> ------------------------------ Subject: Digest Footer _______________________________________________ Python-Dev mailing list -- python-dev(a)python.org To unsubscribe send an email to python-dev-leave(a)python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ ------------------------------ End of Python-Dev Digest, Vol 206, Issue 24 ******************************************* [View Less]

5 4

Call for papers for PyCon 2020
by Amna Ahsan Sept. 13, 2020

Sept. 13, 2020

Hi, I am writing to you on behalf of PyCon Estonia <https://pycon.ee> to invite you to take part in the call for papers for our 2020 edition and join us as a speaker at PyCon: https://pyconestonia.typeform.com/to/e0jriV This is the third PyCon Estonia event after successful delivery in 2018 and 2019. PyCon Estonia is organised by our NGO Python Estonia <https://pythonestonia.ee> which is dedicated to education and awareness about Python in the region. In previous years <https:/… [View More]

2 1

PEP 632: Deprecate distutils module
by Steve Dower Sept. 11, 2020

Sept. 11, 2020

Hi all. setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly without having to rely on patching the standard library. As a result, we can now move forward with official deprecation (in 3.10) and removal (in 3.12) (noting that the distutils docs already recommend switching to setuptools). Full text and discussion at https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 I'm including the … [View More]original text below, but won't be responding to all discussions here (though I'll periodically check in and skim read it, assuming things don't go way off track). Also be aware that I already have some minor changes lined up that are not in this text. Refer to the discussion on Discourse if you need to see those. Cheers, Steve --- PEP: 632 Title: Deprecate distutils module Author: Steve Dower <steve.dower(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 03-Sep-2020 Post-History: Abstract ======== The distutils module [1]_ has for a long time recommended using the setuptools package [2]_ instead. Setuptools has recently integrated a complete copy of distutils and is no longer dependent on the standard library [3]_. Pip has silently replaced distutils with setuptools when building packages for a long time already. It is time to remove it from the (public part of the) standard library. Motivation ========== distutils [1]_ is a largely undocumented and unmaintained collection of utilities for packaging and distributing Python packages, including compilation of native extension modules. It defines a configuration format that describes a Python distribution and provides the tools to convert a directory of source code into a source distribution, and some forms of binary distribution. Because of its place in the standard library, many updates can only be released with a major release, and users cannot rely on particular fixes being available. setuptools [2]_ is a better documented and well maintained enhancement based on distutils. While it provides very similar functionality, it is much better able to support users on earlier Python releases, and can respond to bug reports more quickly. A number of platform-specific enhancements already exist in setuptools that have not been added to distutils, and there is been a long-standing recommendation in the distutils documentation to prefer setuptools. Historically, setuptools has extended distutils using subclassing and monkeypatching, but has now taken a copy of the underlying code. [3]_ As a result, the second last major dependency on distutils is gone and there is no need to keep it in the standard library. The final dependency on distutils is CPython itself, which uses it to build the native extension modules in the standard library (except on Windows). Because this is a CPython build-time dependency, it is possible to continue to use distutils for this specific case without it being part of the standard library. Deprecation and removal will make it obvious that issues should be fixed in the setuptools project, and will reduce a source of bug reports and test maintenance that is unnecessary. It will also help promote the development of alternative build backends, which can now be supported more easily thanks to PEP 517. Specification ============= In Python 3.10 and 3.11, distutils will be formally marked as deprecated. All known issues will be closed at this time. ``import distutils`` will raise a deprecation warning. During Python 3.10 and 3.11, uses of distutils within the standard library may change to use alternative APIs. In Python 3.12, distutils will no longer be installed by ``make install`` or any of the first-party distribution. Third-party redistributors should no longer include distutils in their bundles or repositories. This PEP makes no specification on migrating the parts of the CPython build process that currently use distutils. Depending on contributions, this migration may occur at any time. After Python 3.12 is started and when the CPython build process no longer depends on distutils being in the standard library, the entire ``Lib/distutils`` directory and ``Lib/test/test_distutils.py`` file will be removed from the repository. Other references to distutils will be cleaned up. As of Python 3.9's initial release, the following modules have references in code or comments: * Lib/ctypes/util.py * Lib/site.py * Lib/sysconfig.py * Lib/_aix_support.py * Lib/_bootsubprocess.py * Lib/_osx_support.py * Modules/_decimal/tests/formathelper.py As the distutils code is already included in setuptools, there is no need to republish it in any other form. Those who require access to the functionality should use setuptools or an alternative build backend. Backwards Compatibility ======================= Code that imports distutils will no longer work from Python 3.12. The suggested migration path is to use the equivalent (though not identical) imports from setuptools. Compatibility shims already exist in setuptools and pip to transparently migrate old code, however, these are controlled by external projects and are in no way bound by this PEP. Consult their latest documentation for migration advice. Some projects use alternate sets of shims over distutils, notably, numpy.distutils. [4]_ Where known, these projects have been informed. Many use custom commands or more narrowly scoped patches, mostly constrained to ``setup.py`` files. As these packages are already subject to setuptools being injected by pip, we expect minimal disruption as a result of distutils being removed. Reference Implementation ======================== setuptools version 48 includes the complete copy of distutils, and as such is no longer dependent on the standard library's copy. Most implementation issues they have faced are due to the continuing existence of distutils in the standard library, and so removal will improve the stability of their implementation. There is not yet a reference implementation for the removal of distutils from the standard library, nor is there an implementation for CPython's native module builds without relying on the standard library copy of distutils. References ========== .. [1] distutils - Building and installing Python modules (https://docs.python.org/3.9/library/distutils.html) .. [2] setuptools - PyPI (https://pypi.org/project/setuptools/) .. [3] setuptools Issue #417 - Adopt distutils (https://github.com/pypa/setuptools/issues/417) .. [4] Packaging (numpy.distutils) (https://numpy.org/doc/stable/reference/distutils.html) Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. [View Less]

15 29

Summary of Python tracker Issues
by Python tracker Sept. 11, 2020

Sept. 11, 2020

ACTIVITY SUMMARY (2020-09-04 - 2020-09-11) 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: open 7697 ( +5) closed 45803 (+39) total 53500 (+44) Open issues with patches: 3136 Issues opened (38) ================== #19521: Parallel build race condition on AIX since python-2.7 https://bugs.python.org/issue19521 reopened by skrah #38240: assertCountEqual … [View More]

1 0

RSVP: 2020 Python Core Dev Sprint
by Kyle Stanley Sept. 9, 2020

Sept. 9, 2020

Hey all, We just recently finished working on the signup form for the upcoming 2020 Python Core Dev Sprint on Oct. 19th - 23rd. In addition to getting an general idea of (virtual) attendance, this is being used to assess the topics covered, optimal start/end times for each day, and preferred social activities. Anyone who is a CPython core developer, engaged in a core dev mentorship, or a member of the Python triage team is welcome to attend! Sign up to attend here: https://forms.gle/… [View More]

2 1

Taking over xxlimited for PEP 630
by Petr Viktorin Sept. 9, 2020

Sept. 9, 2020

Hello, The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP 384 (Defining a Stable ABI), and is undocumented. As far as I can tell, it was added partly to test the stable ABI, and partly as an example of how to write a module (like "xx" from xxmodule.c). In the last few years the module has not seen much maintenance, and I believe it's no longer a good example to follow: it works, but there are now better ways to do things. I would like to take over maintenance of the … [View More]

2 1