Mailman 3 June 2019 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

6 11

Python 3.7.4rc1 (and 3.6.9rc1) cutoffs ahead, now set for 2019-06-17
by Ned Deily 30 Jun '19

30 Jun '19

https://discuss.python.org/t/python-3-7-4rc1-and-3-6-9rc1-cutoffs-ahead-now… A reminder: it is time for the next quarterly maintenance release of Python 3.7. The cutoff for **3.7.4rc1** had been scheduled for this coming Monday (2019-06-10) but many of us have been focused on feature code off for 3.8.0, which just took place a few days ago (yay!). So, to give us all a bit more time to attend to 3.7.x matters, I have moved the code cutoff a week, to **Monday 2019-06-17** by the end of day AOE. Please review open issues and ensure that any that you believe need to be addressed in 3.7.4 are either resolved or marked as a **release blocker**. Any assistance you can provide in helping resolve issues will be greatly appreciated! Following the rc1 cutoff, changes merged to the 3.7 branch will be released in 3.7.5 three months from now unless you mark the issue as a release blocker prior to **3.7.4 final**, planned for release on **2019-06-28**, and explain why the change should be cherry-picked into the final release. I am also scheduling for the same dates the rc1 and final releases of Python **3.6.9**, which is the first 3.6 security-fix-only source release since its final bugfix release, 3.6.8, six months ago. If there are any open security issues that you feel should be backported to 3.6, please get them in before its cutoff on **2019-06-17** AoE. Thanks to everyone who has been helping to ensure the continued success of Python 3.6 and 3.7! Our users truly appreciate it and are showing their confidence in us by the rapid adoption of these latest releases. Onward! P.S. I have recently updated the 3.7.x release schedule in PEP 537 to show tentative release dates for the rest of 3.7's bugfix phase. Like with 3.6, we plan to continue having 3.7.x bugfix releases every three months until 2020-06-27, two years after the initial release of 3.7.0. At that point, 3.7.x will enter its security-fix-only phase for an additional three years. https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad(a)python.org -- []

2 2

RSVP: CPython core dev sprint
by Pablo Galindo Salgado 25 Jun '19

25 Jun '19

Hi everyone, I am helping to co-organize together with the PSF the CPython core developer sprint that will take place in London from the 9th to the 13th of September. If you want to attend the core developer sprint, please, self nominate yourself by filling this form: https://docs.google.com/forms/d/e/1FAIpQLSfYJ81qDnclStfzcYfltZViooJLiBCXex4… You need to fill the form even if you don't need PSF support for the travel and accommodation so we can successfully prepare for adequate meeting space and catering. After we have received all responses, Ewa will reach out to you individually with additional information for booking rooms and getting travel reimbursed if you requested it. Please, fill the form before June 14th. Here you can find some information regarding the venue: https://www.bloomberg.com/company/london/ 3 Queen Victoria St London EC4N 4TQ Google Maps: https://goo.gl/maps/sPLba2VqptT2 The support for traveling and the accommodation will be provided by the PSF and the money raised by Pylondinium (https://pylondinium.org/). If you have any questions, requirements or suggestions or you need any support, please, contact me (pablogsal(a)gmail.com) or Ewa (ewa(a)python.org). Thank you very much and I hope to see you in London! Pablo Galindo Salgado

2 2

Core dev sprint 2019 - Mentee nominations
by Pablo Galindo Salgado 24 Jun '19

24 Jun '19

Hi everyone, Thank you all for signing up to the Python core dev sprint for 2019! We are finishing the bookings and preparations and we may have some resources to allow a few mentees to attend the sprint. *If you are attending the sprint* (you have filled the form we sent previously) and *you are mentoring someone* you think would benefit from attending the sprint, you can nominate them. Notice that the nomination does not guarantee that the mentee will receive PSF financial support, as this is tied to how many request we receive and how many resources can be dedicated to this. To nominate your mentee, fill out the following form **before next monday** (1st of July 2019): https://docs.google.com/forms/d/e/1FAIpQLSfxRaNqGby8-Tzj9sTWXiqGCshXjDpM1_P… If you have any questions or you need any support with the form, please, contact me (pablogsal(a)gmail.com) or @ewa.jodlowska <https://discuss.python.org/u/ewa.jodlowska> (ewa(a)python.org). Thank you very much! Regards from rainy London, Pablo Galindo Salgado

2 1

Blurb question: error in Misc/NEWS.d/3.8.0b1.rst
by Eric V. Smith 20 Jun '19

20 Jun '19

I made a typo in a blurb file that's been incorporated into Misc/NEWS.d/3.8.0b1.rst. I referenced an incorrect bpo number. How do I go about fixing it? Can I just modify that .rst file, or is there some other process I need to perform? Eric

2 2

[RELEASE] Python 3.7.4rc1 and 3.6.9rc1 are now available
by Ned Deily 19 Jun '19

19 Jun '19

Python 3.7.4rc1 and 3.6.9rc1 are now available. 3.7.4rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. 3.6.9rc1 is the release preview of the first security-fix release of Python 3.6. Assuming no critical problems are found prior to 2019-06-28, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.4 and security fixes in 3.6.9. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find the release files, a link to their changelogs, and more information here: https://www.python.org/downloads/release/python-374rc1/ https://www.python.org/downloads/release/python-369rc1/ -- Ned Deily nad(a)python.org -- []

1 0

Welcome Paul Ganssle to the Python core team!
by Brett Cannon 16 Jun '19

16 Jun '19

Assuming I didn't mess up, Paul should be set up appropriately at this point.

4 3

Vote to promote Paul Ganssle as a core developer
by Pablo Galindo Salgado 15 Jun '19

15 Jun '19

************************ ********************************************************************************************************* The vote is happening here: https://discuss.python.org/t/vote-to-promote-paul-ganssle-as-a-core-develop… ************************ ********************************************************************************************************* Victor Stinner and I want to propose Paul Ganssle as a core developer, who would center his efforts on co-maintaining datetime together with Alexander Beloposky. Some of you may already know Paul Ganssle as the main maintainer of dateutil, as maintainer of setuptools or for his contributions to CPython. On the technical side, Paul has proven many times to have a great domain knowledge around the datetime module and related functionality but he also has remarkable knowledge about Python and CPython internals. As a reviewer, Paul has made several reviews of datetime-related pull requests but also other general pull requests involving Python and C code as well as documentation. In the reviews he always shows a great care towards the contributor (as can be seen as well in the reviews in the packages that Paul maintains) but also he has spend a lot of time reviewing the wording as a native English speaker, always in a detailed and pedagogical way. Paul always listens to other ideas and viewpoints when discussing and he reacts very positively to criticism in his PRs and work. Paul would like to focus on co-maintain datetime together with Alexander Beloposky (who has expressed that he is ok with that). We consulted with Paul prior to the nomination, and he said he is interested in becoming a core developer so that he can expand his ability to improve the datetime module and CPython in general; he also participates in many sprint events, and it would improve his ability to bring new contributors on to the project. In short, we think Paul is an exceptional developer, a kind and compassionate person, and CPython would benefit from having him on the core team. I have oppened a vote on discuss.python.org ( https://discuss.python.org/t/vote-to-promote-paul-ganssle-as-a-core-develop…) for 1 week. As a reminder from PEP 13 regarding voting rules: >... It is granted by receiving at least two-thirds positive votes in a core team vote that is open for one week and with no veto by the steering council." https://www.python.org/dev/peps/pep-0013/#membership Here is a summary of Paul's work and achievements: ## Background Information about Paul Ganssle 1. Maintainer of dateutil since 2014. First and most prominent third-party implementation of PEP 495 (Local Time Disambiguation). 2. Maintainer of setuptools since 2018. 3. Frequently run sprints on dateutil and setuptools. Would like to be able to offer mentorship on CPython at conference sprints. 4. Organized and ran the PyPA mini-summit at PyCon US 2018 and 2019, active in the PyPA generally. 5. Wrote datetime bindings for PyO3 (CPython bindings for Rust), and has continued to contribute regularly to that project with PRs, reviews and issues. Interested in contributing to the C API from the perspective of someone writing cross-language bindings. 6. Frequently helps maintain datetime-related code on other projects: - `pandas`: [Issue 23959]( https://github.com/pandas-dev/pandas/issues/23959), [issue 18523]( https://github.com/pandas-dev/pandas/issues/18523), [PR 19281]( https://github.com/pandas-dev/pandas/pull/19281), [PR 22560]( https://github.com/pandas-dev/pandas/pull/22560) - `matplotlib`: [PR 12678]( https://github.com/matplotlib/matplotlib/pull/12678), [issue 9018]( https://github.com/matplotlib/matplotlib/issues/9018), [PR 11610]( https://github.com/matplotlib/matplotlib/pull/11610), [PR 11360]( https://github.com/matplotlib/matplotlib/pull/11360) - `jupyter`: [jupyter-widgets/ipywidgets#168]( https://github.com/jupyter-widgets/ipywidgets/issues/168#issuecomment-14758… ) 7. Spoke at the language summit about adding more time zones to the standard library. [Slides]( https://pganssle-talks.github.io/pycon-us-2019-language-summit-tz/#/), [Repo](https://github.com/pganssle-talks/pycon-us-2019-language-summit-tz) ### Major accomplishments in CPython 1. Implemented `datetime.fromisoformat`, the inverse of `datetime.isoformat`. This is still the fastest constructor for `datetime` accessible from Python. ([PR #4699]( https://github.com/python/cpython/pull/4699), [PR #8959]( https://github.com/python/cpython/pull/8959)) 2. Exposed `datetime.timezone` and `datetime.timezone.utc` in the CPython API. ([PR #5032](https://github.com/python/cpython/pull/5032)) 3. Implemented and made the case for changing the return type of `datetime` + `timedelta` arithmetic to respect the subclass of the `datetime` object. Similarly has been working to make `datetime` safer to subclass in general. ([PR #10902](https://github.com/python/cpython/pull/10902), [Python-dev thread 1]( https://mail.python.org/pipermail/python-dev/2019-January/155984.html) [2]( https://mail.python.org/pipermail/python-dev/2019-February/156206.html)) 4. Improved the speed of all `datetime` alternate constructors. ([PR #4993]( https://github.com/python/cpython/pull/4993)) 5. Add `datetime.fromisocalendar`, the inverse function from `datetime.isocalendar` in [PR #11888]( https://github.com/python/cpython/pull/11888). Intends to continue improving and maintaining symmetry between "serialization" and "deserialization" functions. ### General maintenance tasks 1. Generally follows and comments on datetime and packaging related issues in the issue tracker, among other things. 2. Reviews PRs, generally to datetime and time, but also unrelated PRs (e.g. [PR #7605](https://github.com/python/cpython/pull/7605) adding `shlex.join`). Also has been trying to help give a native English speaker's perspective on documentation PRs. ### Future plans During our discussion, Paul has provided a list of improvements to Python he'd like to make: 1. Improve Python datetime C API test suite and documentation (partially completed at the PyCon sprints, Paul created the issues and helped Edison Abahurire with reviews and in-person guidance while he made his first pull requests adding tests and documentation for the datetime C API). 2. Expand time zone support in the standard library with a concrete implementation of IANA time zones and an explicit representation of "local" time. 3. Add nanosecond support to `datetime` 4. Improve compatibility across platforms where possible in things like `strftime` and `timestamp`. 5. Improve locale-specific testing Most of this is datetime related because that is the primary area where his expertise is most needed (plus most packaging changes occur on `setuptools` itself and not `distutils`), but he is interested in general contributions to the language as well. ### Contributions - PRs authored: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Ap… - PRs reviewed: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+reviewed-b… #### Selected bpo issues - strftime() returns wrong week numbers: https://bugs.python.org/issue35841 - warning about potential dead code: https://bugs.python.org/issue36330 - Wrong inspect.getsource for datetime: https://bugs.python.org/issue32313 - fromisoformat doesn't handle "Z": https://bugs.python.org/issue35829 - sqlite3 optional auto-conversion of DATETIME fields: https://bugs.python.org/issue35145 - Incorrect documentation for strftime(): https://bugs.python.org/issue33381 - Second run of 2to3 modifies output: https://bugs.python.org/issue36122 (companion issue where he suggested keeping it open: https://bugs.python.org/issue35417 ) - Replace append loops with comprehensions: https://bugs.python.org/issue36039 - datetime.time.isoformat has inconsistent behavior: https://bugs.python.org/issue34407

3 2

Reminder: Core Developer Sprint RSVP Deadline Tomorrow!
by Pablo Galindo Salgado 13 Jun '19

13 Jun '19

Hi, just a reminder everyone: June 14th (tomorrow) is the deadline to respond to the core developer sprint RSVP form: https://docs.google.com/forms/d/e/1FAIpQLSfYJ81qDnclStfzcYfltZViooJLiBCXex4… For that needing assistance with hotel, be sure to fill out the form by the deadline otherwise we may not book enough hotel rooms. If for any reason you cannot answer by June 14th, please contact me ( pablogsal(a)gmail.com) and Ewa (ewa(a)python.org). Thank you very much, Pablo Galindo Salgado

1 0

Fwd: Python-checkins post from webhook-mailer@python.org requires approval
by Terry Reedy 09 Jun '19

09 Jun '19

Some years ago I was added to python-checkins as a moderator, but not a full list owner, to occasionally discard the very occasional spam. I don't know who the real list owner is, if anyone. Recently, checkins from Łukasz Langa are being held. I have no idea why, or what implicit destination means. Whoever understands this part of the infrastructure and know how to fix this should do do. I will not continue to approve these on anything like a timely basis. This list should have a knowledgable list owner who pays attention to proper checkins improperly held for moderation. --------------------------------------------------------------------- As list administrator, your authorization is requested for the following mailing list posting: List: Python-checkins(a)python.org From: webhook-mailer(a)python.org Subject: (no subject) Reason: Message has implicit destination At your convenience, visit: https://mail.python.org/mailman/admindb/python-checkins to approve or deny the request. ----------------------------------------------------------------------------- ForwardedMessage.eml From: Łukasz Langa <webhook-mailer(a)python.org> To: python-checkins(a)python.org Subject: Add some placeholder notes for major 3.8 features (GH-13927) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 https://github.com/python/cpython/commit/b9438ceb20635b00f10615c5b6d8dbe56e… 486b commit: b9438ceb20635b00f10615c5b6d8dbe56e1d486b branch: master author: Nick Coghlan <ncoghlan(a)gmail.com> committer: =C5=81ukasz Langa <lukasz(a)langa.pl> date: 2019-06-09T11:07:42+02:00 summary: Add some placeholder notes for major 3.8 features (GH-13927) files: M Doc/whatsnew/3.8.rst diff --git a/Doc/whatsnew/3.8.rst b/Doc/whatsnew/3.8.rst index bf75387d9517..99bb793830bc 100644 --- a/Doc/whatsnew/3.8.rst +++ b/Doc/whatsnew/3.8.rst @@ -52,6 +52,13 @@ For full details, see the :ref:`changelog <changelog>`. form. It will be updated substantially as Python 3.8 moves towards releas= e, so it's worth checking back even after reading earlier versions. =20 + Some notable items not yet covered here: + + * :pep:`574` - Pickle protocol 5 with out-of-band data buffer support + * :pep:`578` - Runtime audit hooks for potentially sensitive operations + * ``python -m asyncio`` runs a natively async REPL + * ... + =20 Summary -- Release highlights =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ------------------------------------------------------------------------- ForwardedMessage.eml From: Łukasz Langa <webhook-mailer(a)python.org> To: python-checkins(a)python.org Subject: bpo-36785: PEP 574 What's New entry (#13931) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 https://github.com/python/cpython/commit/c879ff247ae1b67a790ff98d2d59145302… 4e4e commit: c879ff247ae1b67a790ff98d2d59145302cd4e4e branch: master author: Antoine Pitrou <antoine(a)python.org> committer: =C5=81ukasz Langa <lukasz(a)langa.pl> date: 2019-06-09T14:47:15+02:00 summary: bpo-36785: PEP 574 What's New entry (#13931) files: M Doc/whatsnew/3.8.rst diff --git a/Doc/whatsnew/3.8.rst b/Doc/whatsnew/3.8.rst index 99bb793830bc..e2f9ce8dd6e5 100644 --- a/Doc/whatsnew/3.8.rst +++ b/Doc/whatsnew/3.8.rst @@ -54,7 +54,6 @@ For full details, see the :ref:`changelog <changelog>`. =20 Some notable items not yet covered here: =20 - * :pep:`574` - Pickle protocol 5 with out-of-band data buffer support * :pep:`578` - Runtime audit hooks for potentially sensitive operations * ``python -m asyncio`` runs a natively async REPL * ... @@ -261,6 +260,23 @@ See :pep:`590` for a full description. (Contributed by Jeroen Demeyer and Mark Shannon in :issue:`36974`.) =20 =20 +Pickle protocol 5 with out-of-band data buffers +----------------------------------------------- + +When :mod:`pickle` is used to transfer large data between Python processes +in order to take advantage of multi-core or multi-machine processing, +it is important to optimize the transfer by reducing memory copies, and +possibly by applying custom techniques such as data-dependent compression. + +The :mod:`pickle` protocol 5 introduces support for out-of-band buffers +where :pep:`3118`-compatible data can be transmitted separately from the +main pickle stream, at the discretion of the communication layer. + +See :pep:`574` for a full description. + +(Contributed by Antoine Pitrou in :issue:`36785`.) + + Other Language Changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20

2 1