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
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 -- []
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
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
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
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 -- []
************************
*********************************************************************************************************
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
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
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