Mailman 3 January 2018 - 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

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 Dec '18

17 Dec '18

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 1

I created the "needs backport to 3.7" label on GitHub
by Mariatta Wijaya 02 Feb '18

02 Feb '18

I noticed that there is a 3.7 branch now. So you can use this label if you want miss-islington to backport a PR to 3.7.

5 5

3.7.0b1 status
by Ned Deily 31 Jan '18

31 Jan '18

Just a quick update: thanks to all of you who worked long hours to get features completed and merged in for the 3.7 feature code cutoff yesterday. We release elves have been busy behind the scenes baking goodies. So far everything looks OK. But we're taking a little longer than usual: this is, in many ways, the most complicated milestone of the release cycle, since it involves creating a new release branch and other munging, and this is the first time we are doing this since we moved to our new git-based workflow last year and we want to get it right. We will have everything done and announced in not more than 24 hours from now. If you wish, feel free to merge new commits into the master branch for release in 3.8, with the understanding that any also destined for 3.7.0 will need to be cherrypicked after the 3.7 branch is available. Other branches (3.6, 2.7) are unaffected. Thanks for your patience! -- Ned Deily nad(a)python.org -- []

2 3

Adding "Co-authored-by" in commit message.
by Mariatta Wijaya 30 Jan '18

30 Jan '18

I learned today that GitHub now supports multiple author info in a commit. https://help.github.com/articles/creating-a-commit-with-multiple-authors/ and https://github.com/blog/2496-commit-together-with-co-authors It can be done by adding: Co-authored-by: name <email address> as the footer of the commit message. I tested this in CPython: https://github.com/python/cpython/commit/6ea75b174da0cf824e2acc5db6b53798f5… I suggest we start adding this where it makes sense, to give proper credit to PR authors. What I've seen is that we've only been writing "Original Patch by <someone else>". One scenario is when we convert someone else's mercurial patch to GitHub pull request. Or when someone started a patch, and another person finished it. The other scenario is with miss-islington's backport PRs. I will try to find time this week so that miss-islington or cherry_picker will add the "Co-authored-by:" automatically. Mariatta Wijaya

2 2

Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!
by Barry Warsaw 27 Jan '18

27 Jan '18

As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature freeze. I think we can all give Ned a huge round of applause for his amazing work as Release Manager for Python 3.6 and 3.7. Let’s also give him all the support he needs to make 3.7 the best version yet. As is tradition, Python release managers serve for two consecutive releases, and so with the 3.7 release branch about to be made, it’s time to announce our release manager for Python 3.8 and 3.9. By unanimous and enthusiastic consent from the Python Secret Underground (PSU, which emphatically does not exist), the Python Cabal of Former and Current Release Managers, Cardinal Ximénez, and of course the BDFL, please welcome your next release manager… Łukasz Langa! And also, happy 24th anniversary to Guido’s Python 1.0.0 announcement[1]. It’s been a fun and incredible ride, and I firmly believe that Python’s best days are ahead of us. Enjoy, -Barry [1] https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo…

5 6

IMPORTANT: 3.7.0b1 and feature code cutoff 2018-01-29
by Ned Deily 27 Jan '18

27 Jan '18

Happy mid-winter (northern hemisphere) or -summer (southern)! The time has come to finish feature development for Python 3.7. As previously announced, this coming Monday marks the end of the alpha phase of the release cycle and the beginning of the beta phase. Up through the alpha phase, there has been unrestricted feature development phase; that ends as of beta 1. All feature code for 3.7.0 must be checked in by the b1 cutoff on end-of-day Monday (unless you have contacted me and we have agreed on an extension). As was done during the 3.6 release cycle, we will create the 3.7 branch at b1 time. During the beta phase, the emphasis is on fixes for new features, fixes for all categories of bugs and regressions, and documentation fixes/updates. I will send out specific information for core committers next week after the creation of the b1 tag and the 3.7 branch. Beta releases are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.7 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release will be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase. Our goal is have no changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Also, during the 3.6.0 release cycle, the question of ABI stability during the final (e.g. beta and release candidate) phases of the release came up. Last-minute changes put a burden on our and our downstream users testing efforts and adds risk to the release. Therefore, as was proposed then, we will strive to have no ABI changes after beta 3. More details forthcoming. To recap: 2018-01-29 ~23:59 Anywhere on Earth (UTC-12:00): code snapshot for 3.7.0 beta 1 (feature code freeze, no new features) 2019-01-30: 3.7 branch opens for 3.7.0 feature development continues on master branch, now for 3.8.0 2018-01-30 to 2018-05-21: 3.7.0 beta phase (bug, regression, and doc fixes, no new features) 2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze) 2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze) 2018-06-15: 3.7.0 release (3.7.0rc1 plus, if necessary, any dire emergency fixes) ~2019-12 tentative (3.7.0 release + 18 months): 3.8.0 release (details TBD) Thank you all for your great efforts so far on 3.7; it should be another great release! --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad(a)python.org -- []

1 0

core developer status
by Xavier de Gaye 27 Jan '18

27 Jan '18

I have decided for personal reasons to stop contributing to CPython as a core developer, that does not mean I will stop contributing to CPython. So please remove me from the list of core developers and revoke all my access rights. Thank you. Xavier

4 3

ssl module will require OpenSSL 1.0.2
by Christian Heimes 27 Jan '18

27 Jan '18

For your information, my ssl module improvement "Let OpenSSL verify hostname and IP address" will land either today or tomorrow. I'm just waiting for Alex to give me the final ACK on PR https://github.com/python/cpython/pull/3462. Once the PR has landed, several issues with hostname and IP address verification will be solved. Python 3.7 will use OpenSSL's recommended API to match hostnames. The API is OpenSSL 1.0.2+ only. OpenSSL 0.9.8 and 1.0.1 are no longer supported. LibreSSL does not yet implement these APIs yet, see https://github.com/libressl-portable/portable/issues/381 for my upstream bug and https://mail.python.org/pipermail/python-dev/2018-January/151824.html for Python-dev discussion. I also like to get https://github.com/python/cpython/pull/5259 into 3.7. The PR adds support for OpenSSL's new API to set minimum and maximum TLS protocol version. It's require for compatibility with future versions of Debian. Debian has used the new APIs to disable TLS 1.0 and 1.1, see https://bugs.python.org/issue31453. PR https://github.com/python/cpython/pull/5162 implements PEP 543 Certificate and PrivateKey classes, but it's not finished yet. The code works but it lacks tests and documentation. My remaining TLS PRs are either bug fixes or can wait for 3.8. I'll merge them after beta 1 has been released. Christian

4 7

AppVeyor is now required to pass on PRs
by Brett Cannon 27 Jan '18

27 Jan '18

I just switched it on to help make sure we don't break on Windows just before hitting beta. If it turns out AppVeyor isn't stable enough I will switch it back off.

8 12