python-committers May 2020

python-committers@python.org

16 participants
13 discussions

Recent changes on the CI jobs run on pull requests
by Victor Stinner 09 Jun '20

09 Jun '20

Hi, Changes on CIs run on GitHub pull requests: * Travis CI became mandatory * Azure Pipelines is no longer mandatory * Please watch Windows x64 job: I would like to make it mandatory in 2 weeks -- I asked to make Azure Pipelines CI not mandatory on Python PRs since there were more and more random failures and no one was available to investigate. Also, sadly, currently Azure Pipelines has no way to only re-trigger a single failed job, but requires to close/re-open a PR to schedule all jobs. Sadly, some Python tests fail randomly and so sometimes another CI fails. Also, for backport PRs, closing a PR triggers miss-inlington which removes the branch which prevents to re-open the PR. A new backport PR must be created which is not convenient. Until Azure Pipelines issues are fixed, I asked Mariatta to make Travis CI mandatory. In fact, I expected Travis CI to be mandatory, I never noticed that it was optional. I didn't know that only Azure Pipelines was mandatory! -- I also asked Mariatta to make the GitHub Action ("GHA") Windows x64 job mandatory. GHA workflow jobs are skipped for "documentation only" changes, to not waste CI resources. GHA configuration used "paths-ignored". Sadly (again!?), if a job using "paths-ignored" is mandatory, a PR cannot be merged because the mandatory job is skipped and will never be run... Sadly, it even seems to be a known GitHub issue which is not going to be fixed soon! I removed "paths-ignored" to always run jobs, to be able to make a job mandatory. Then Filipe Laíns found a way to add a new quick (around 15 seconds!) job just for check if a change is documentation only: the job result is then used to decide if build jobs must be skipped. In short, the behavior is the same than previously: GHA build jobs are skipped on documentation only changes. The main difference is that it became possible to make a GHA job mandatory. I backported the GHA workflow configuration to Python 3.8 and 3.7. Mariatta suggested to watch the Windows x64 job for 2 weeks to check if it's stable before making it mandatory. Hopefully, in my experience, the Windows x64 job is (very) reliable. -- By the way, the GHA macOS job fails randomly, I have no idea why. For example, I saw the job being cancelled after 5 minutes for an unknown reason. I read that a job can be cancelled if "fail fast" is used and another job fails. It doesn't seem like we use "fail fast" and others jobs passed successfully. -- Links to CI changes. Make Azure Pipelines optional on GitHub PRs: https://bugs.python.org/issue39837 Always run GitHub action jobs, even on documentation-only jobs: https://bugs.python.org/issue40548 Make one Windows CI job mandatory: https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047 Make Travis CI (and Windows x64 ?) mandatory: https://github.com/python/core-workflow/issues/365 Make Windows (x64) GitHub action mandatory on master branch: https://github.com/python/core-workflow/issues/368 -- It's so hard to get a bunch of reliable CIs on many platforms (Linux, Windows, macOS) and minimize the failure rate :-( Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 1

Guido van Rossum Core Developer Grant & EuroPython
by M.-A. Lemburg 26 May '20

26 May '20

Dear follow core developers, I would like to invite you to attend this year's EuroPython conference: https://ep2020.europython.eu/ The conference will be held online from July 23-26 and we took special care to add slots which can easily be followed from pretty all around the world. The first two days are conference days, with over 110 sessions. We'll announce the schedule preview in the coming days. We'll also have sprints on the weekend of July 25-26 where teams can get together in Jitsi or Zoom rooms and use our Discord server to chat: https://ep2020.europython.eu/events/sprints/ This would make a great platform for a CPython sprint or for a specific CPython project. Joining sprints is free and we already have quite a few signups, so this would be a great way to find more potential core developers. Since you are core developers, joining the conference will be particularly easy as well. In 2018, the EuroPython Society (EPS) decided to put up a Guido van Rossum Core Developer Grant, which allows core developers to get free tickets to all future EuroPython conferences: https://www.europython-society.org/core-grant Would be great to meet some of you at the event. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 26 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

1 0

Remove accidentally created branch on cpython repo
by Kyle Stanley 21 May '20

21 May '20

Hey all, So by my own mistake in the GitHub UI, I was looking at a previous commit for one of my PRs (https://github.com/python/cpython/pull/19282) and misclicked the "revert commit" button instead of "view details". Fortunately, this only created a separate branch in the cpython repository instead of actually reverting anything (see https://github.com/python/cpython/tree/revert-19282-bpo40115-test_asyncio-r…), but I'm unsure of the best way to remove the branch or if I'm even able to. Sorry about the mixup, I'm rather new to the core developer role and this is my first time running into anything like this. Regards, Kyle Stanley

2 2

Re: [Python-Dev] Re: Please welcome our next Release Manager, Pablo!
by Victor Stinner 19 May '20

19 May '20

Le mer. 20 mai 2020 à 02:39, Terry Reedy <tjreedy(a)udel.edu> a écrit : > First, with 2.x really past us, is removing remaining long deprecated > features, plus some others advocated for removal. I think these are > best done by the first alpha so that early testers are rewarded with an > early opportunity to change their code or else object to the removal. I tried to remove as much deprecated features as possible at the beginning of the 3.9 dev cycle. Many people contributed to this task, see the length of the Removal section :-) https://docs.python.org/dev/whatsnew/3.9.html#removed Later, aliases to ABC in the collections and the "U" mode of open() were reverted in 3.9, with the idea of removing them again in 3.10. Just to give one cycle to the community to drop Python 2 and fix these deprecation warnings. The What's New In Python 3.9 documentation starts with a long warning about deprecation warnings: https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecat… Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

Please welcome our next Release Manager, Pablo!
by Barry Warsaw 19 May '20

19 May '20

In light of the release of Python 3.9b1, let’s take a moment to celebrate all the great work that our Python 3.8 and 3.9 release manager Łukasz has done. The role of Python Release Manager is hugely important to each successful release, and it can be a lot of work, often unseen and thankless to shepherd a new Python version through its first alpha release to its last security release. With all of your immeasurable help, the Release Manager ensures solid, feature-full releases that the entire Python community eagerly awaits. Łukasz carries on the fine tradition of all of our past release managers, and now that his second release has entered beta phase, I’m very happy to announce our next Release Manager, for Python 3.10 and 3.11: Pablo Galindo Salgado! Since becoming a core developer in 2018, Pablo has contributed significantly to Python. With the change to an annual release cycle (PEP 602, authored by Łukasz), the time commitment for release managers has been reduced as well, and we will continue to look for ways to make the selection process for release managers more transparent and accessible. I know that in addition to admirably managing the releases for 3.10 and 3.11, Pablo will also help to continually improve the process of selecting and serving as release manager. Please join me in welcoming Pablo in his new role! Cheers, -Barry

6 5

Heads up: the master branch now points to Python 3.10
by Łukasz Langa 19 May '20

19 May '20

Along with the release of Python 3.9.0b1, a 3.9 maintenance branch was created and the master branch now holds work that will become Python 3.10a1 at some point. This change was made here: https://github.com/python/cpython/pull/20198 <https://github.com/python/cpython/pull/20198> Note that this means you have to have your bugfix pull requests backported to 3.9 using the newly created GitHub label. If you don't do this, they will only be available in Python 3.10. Note I wrote bugfix pull requests. We entered the beta phase and new features will have to wait until next year's release. Creating a new maintenance branch is the most manual piece of the release process we have. If you notice any place where Python 3.10 is missing in a list, or that suggests that master is still Python 3.9, let me know and we'll handle it. Thank you to Victor Stinner who proactively found a bunch of those things very quickly. (Julien is taking care of the JS version pickers in the docs.) Cheers! - Ł

1 0

[Python-Dev] [RELEASE] Python 3.9.0b1 is now available for testing
by Łukasz Langa 19 May '20

19 May '20

On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of Python 3.9.0b1. Get it here: https://www.python.org/downloads/release/python-390b1/ <https://www.python.org/downloads/release/python-390b1/> This is a beta preview of Python 3.9 Python 3.9 is still in development. This release, 3.9.0b1, is the first of four planned beta release previews. Beta release previews 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. Call to action We strongly encourage maintainers of third-party Python projects to test with 3.9 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to 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 (2020-08-10). Our goal is have no ABI changes after beta 4 and as few code changes as possible after 3.9.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.9 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.9 series, compared to 3.8 Some of the new major new features and changes in Python 3.9 are: PEP 584 <https://www.python.org/dev/peps/pep-0584/>, Union Operators in dict PEP 585 <https://www.python.org/dev/peps/pep-0585/>, Type Hinting Generics In Standard Collections PEP 593 <https://www.python.org/dev/peps/pep-0593/>, Flexible function and variable annotations PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence PEP 616 <https://www.python.org/dev/peps/pep-0616/>, String methods to remove prefixes and suffixes PEP 617 <https://www.python.org/dev/peps/pep-0617/>, New PEG parser for CPython BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects; BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals; BPO 39926 <https://bugs.python.org/issue39926>, Unicode support updated to version 13.0.0; BPO 1635741 <https://bugs.python.org/issue1635741>, when Python is initialized multiple times in the same process, it does not leak memory anymore; A number of Python builtins (range, tuple, set, frozenset, list, dict) are now sped up using PEP 590 <https://www.python.org/dev/peps/pep-0590> vectorcall; A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, resource, time, _weakref) now use multiphase initialization as defined by PEP 489 <https://www.python.org/dev/peps/pep-0489/>; A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>. (Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:lukasz(a)python.org>.) The next pre-release, the second beta release of Python 3.9, will be 3.9.0b2. It is currently scheduled for 2020-06-08. More resources Online Documentation <https://docs.python.org/3.9/> PEP 596 <https://www.python.org/dev/peps/pep-0596/>, 3.9 Release Schedule Report bugs at https://bugs.python.org <https://bugs.python.org/>. Help fund Python and its community <https://discuss.python.org/psf/donations/>. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

1 0

All hands on deck: the release of Python 3.9.0b1 is currently blocked
by Łukasz Langa 18 May '20

18 May '20

Hi there fellow core developers, the beta 1 release of Python 3.9.0 planned for today is as of now blocked on three issues marked as "release blocker": - https://bugs.python.org/issue26317 <https://bugs.python.org/issue26317> - https://bugs.python.org/issue40661 <https://bugs.python.org/issue40661> - https://bugs.python.org/issue40257 <https://bugs.python.org/issue40257> If you can help addressing those ASAP, please do. We need to tag beta1 this week to help getting the new release on time for inclusion in Linux distributions. - Ł

2 2

Core Workflow change: new commit to previously approved PR now requires re-review
by Mariatta 15 May '20

15 May '20

X-post to python-committers, python-dev, and core-workflow mailing list I have just deployed a change to bedevere-bot to address the security concern related to automerging.( https://github.com/python/core-workflow/issues/325) Previously, if core dev has approved the PR and applied the "automerge" label, the PR will be automatically merged as soon as all the required CI checks passed. If the PR author added another commit after the PR has been approved but before the automerge happened, the additional commit will get merged in without additional review. Now, if there is a new commit after the PR has been approved, it will not be automerged until the the core dev re-reviews it. bedevere will remove the "awaiting merge" label and apply the "awaiting core review" label. Hope this all makes sense. And if you see any of the bot misbehaving, please open a ticket either in core-workflow repo or in the bot's own repo. Thanks.

1 0

Python Language Summit 2020 blog posts
by Mariatta 15 May '20

15 May '20

(x-posting to python-dev and python-committters) Just wanted to share that the first 7 of 11 blog posts about presentations and discussions from Python Language Summit are now up for your enjoyment. Main article: https://pyfound.blogspot.com/2020/04/the-2020-python-language-summit.html Day 1: All strings become f-strings, Eric V Smith: https://pyfound.blogspot.com/2020/04/all-strings-become-f-strings-python.ht… Replacing CPython’s Parser with a PEG-based parser, Pablo Galindo, Lysandros Nikolaou, Guido van Rossum: https://pyfound.blogspot.com/2020/04/replacing-cpythons-parser-python.html A Formal Specification for the (C)Python Virtual Machine, Mark Shannon: https://pyfound.blogspot.com/2020/04/a-formal-specification-for-cpython.html HPy: a Future-Proof Way of Extending Python?, Antonio Cuni: https://pyfound.blogspot.com/2020/04/hpy-future-proof-way-of-extending.html CPython Documentation: The Next 5 Years, Carol Willing, Ned Batchelder: https://pyfound.blogspot.com/2020/04/cpython-documentation-next-5-years.html Day 2: Lightning talks: ( https://pyfound.blogspot.com/2020/04/lightning-talks-part-1.html) - What do you need from pip, PyPI, and packaging?, Sumana Harihareswara - A Retrospective on My "Multi-Core Python" Project, Eric Snow The Path Forward for Typing, Guido van Rossum: https://pyfound.blogspot.com/2020/04/the-path-forward-for-typing-python.html Stay tuned for more posts! Property-Based Testing for Python Builtins and the Standard Library, Zac Hatfield-Dodds Core Workflow Updates, Mariatta Wijaya CPython on Mobile Platforms, Russell Keith-Magee Few more lightning talks from Eric Holscher and Zac Hatfield-Dodds Enjoy!

3 4

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers May 2020