Mailman 3 April 2021 - python-committers

Call for resumes: Developer-in-Residence to support CPython
by Ewa Jodlowska 20 Jul '21

20 Jul '21

Hello! Through a collaboration, the PSF and SC scoped the role for a Developer-in-Residence. We are now accepting resumes -- see below for details. I am super happy to finally set this in motion! If you have any questions, don't hesitate to reach out. Ee and I are on apply@ so feel free to send questions there as well. A blog will be posted later today informing the community. ------------------------------------------------------------------ The Python Steering Council and the Python Software Foundation are looking to hire a Developer-in-Residence! Background CPython, the reference implementation of Python, is developed and primarily maintained by volunteers. Inspired by the Django Fellowship Program's success ( https://www.djangoproject.com/fundraising/), the PSF has strategically planned to support CPython in a similar way beginning this year. Thanks to the support from sponsors such as Google, this effort is moving forward. The Developer-in-Residence will work full-time for one year to assist CPython maintainers and the Steering Council. Areas of responsibility will include analytical research to understand the project's volunteer hours and funding, investigation of project priorities and their tasks going forward, and begin working on those priorities. We are looking to hire an existing core developer because of the type of work involved and interaction with volunteer core developers and contributors. Need and available funding will determine any extension beyond the first year. Job Description This Developer-in-Residence will continually coordinate with PSF staff and the Steering Council on the following tasks (note: this is not an exhaustive list of all tasks, but an overview of desired outcomes): - Create metrics based on: - Surveying maintainers and community to capture: - a directory showing who maintains what standard library module - interest in maintaining standard library modules - which standard library modules are most important to users - Combine usage and surveyed metrics to determine which standard library modules need help and what the maintainer cost is for standard library modules - Determine additional intersections of data that could be useful - Address Pull Request and Issue backlogs based on the developed metrics and other metrics created by the Steering Council - Create a long-term plan for addressing the backlog - Review personally pull requests & triage issues - Help coordinate core developers/maintainers of specific modules to review pull requests and triage issues - Help maintaining, improving and stabilizing the CPython test suite, including the continuous integration infrastructure and buildbot fleet. - Attend Steering Council meetings quarterly and have regular communications with the PSF staff - Organize virtual sprints (i.e., at PyCon US) to collaborate with other Python core developers to grow the community of Python core developers and simultaneously close a large number of existing issues and pull requests - Provide transparency by proposing and fulfilling a public record as agreed to by the Steering Council and PSF Staff - Publish two blogs on pyfound.blogspot.com throughout the year informing the community on progress (halfway through and at the end of the residency) Necessary skills - Strong project management skills - Must be very organized and detail-oriented - Experience working with CPython volunteers - Excellent written and verbal communication - Experience working with software development teams remotely - Ability to balance demand and prioritize An active maintainer of CPython is preferred. Interested in this position? If you are interested, please send an email to apply(a)python.org with your resume (please include community contributions). The call for resumes will be open until May 16, 2021, AoE. Employment/vendor arrangement will depend on whether the person resides in or outside of the US.

9 11

Vote to promote Irit Katriel
by Brett Cannon 30 Apr '21

30 Apr '21

https://discuss.python.org/t/vote-to-promote-irit-katriel/8457

3 4

Irrelevant .whl attachment to tracker issue
by Terry Reedy 29 Apr '21

29 Apr '21

https://bugs.python.org/issue41608 Userid ttx11529 uploaded, without posting anything, a file called pb_tool-3.1.0-py3-none-any.whl. As best I understand, if the name is not forged, this is a file that pip would use to install pb_tool 3.1.0 to any 3.x python. https://pypi.org/project/pb-tool/ "pb_tool provides commands to deploy and publish a QGIS Python plugin." The user list gives the real name as ปพนพัชร์ บรรพจันทร์. Translate.google.com identifies this as Thai, transliterated to Paphon Phatch Banchan. This user's only other tracker activity so far was adding self as nosy to https://bugs.python.org/issue43651 45 min before uploading this file. This could be a clueless newbie, an ordinary spammer, or a malware spreader. Should anything be done other than marking the file as spam and unlinking it? Does anyone know how to safely examine the file, and care to? Terry

3 2

[Release management team communication] 3.8.10, the last regular bugfix release for the 3.8 series, is 1 week away
by Łukasz Langa 27 Apr '21

27 Apr '21

Hi there, one week from now I will be marking the 3.8 branch as "security fixes only". I still see activity on the branch, and there's been a bunch of open pull requests. I reviewed and merged what I could, closed a few stale ones that had outstanding failing tests, and there's still two left which I pinged. I do realize that stars aligned and we will be releasing this last bugfix version of 3.8 at the same time as 3.9.5, and more importantly 3.10.0 beta 1. So there might still be some backport pull requests coming my way for 3.8. This is all good and expected, just be a little conservative whether it makes sense to backport a particular change. While there's still 2200 open issues on BPO listing 3.8 as one of the affected versions, I hope we won't be seeing that many PRs this week ;-) I'm personally rooting for https://github.com/python/cpython/pull/25274 <https://github.com/python/cpython/pull/25274> to get in. In any case, on Monday, May 3rd at 12pm CEST I will be cutting the 3.8.10 release. Any regular bugfix not merged and buildbot-tested by then will be omitted. If you need to block this release for any reason, use the BPO "release blocker" status and mark 3.8 as an affected version. 3.9.5 being less urgent will be made on the same day after 3.8.10 is up on python.org <http://python.org/>. - Ł

2 1

[Release management team communication] 3.10 feature freeze is 1 week away
by Pablo Galindo Salgado 26 Apr '21

26 Apr '21

Hi everyone, This is the last friendly reminder from the release management team that Python 3.10 feature freeze is a week away (Monday, 3 May 2021). Some important things to have in mind: * We have some release blockers that must be resolved before the release is done: https://bugs.python.org/issue43908 https://bugs.python.org/issue43933 https://bugs.python.org/issue43916 If you want to help making sure that the release is on time, help us resolving those blockers. You can also search the issues in https://bugs.python.org/issue?@template=search&status=1 with the "release-blocker" priority. * Please, don't wait until the last moment (Sunday) to merge PRs into master. This is because if many changes accumulate into a time window and problems are detected, is much more difficult to locate the problematic changes among the rest. If there are any problems with your commits, you also would have the risk of having your changes reverted to unblock the release without any time window to merge them again before feature freeze. Please, also be aware of the following: * No new features or improvements should be merged after the feature freeze. From the devguide (https://devguide.python.org/devcycle/#beta) : > After a first beta release is published, no new features are accepted. Only bug fixes and improvements to documentation and tests can now be committed. > This is when core developers should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases. > Being in beta can be viewed much like being in RC but without the extra overhead of needing commit reviews. * If your change involves some platform-specific behaviour or has a non-trivial amount of C code, make sure you run the buildbots in your Pull Request by using the "test-with-buildbots" label ( https://discuss.python.org/t/now-you-can-test-a-pr-with-the-buildbots-befor… ). Alternatively you could check the buildbots post-merge in the buildbot server: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Bstable This is very important because if problems are detected at the time of the release, the release management team may have to revert the changes and therefore those will not be included in Python 3.10. * The master branch will be renamed to main (check our previous communication about how this will be done and how you should proceed https://mail.python.org/archives/list/python-dev@python.org/thread/QWW7KGBW… ) If you have any questions or concerns, please contact me as soon as possible. Regards from sunny London, Pablo Galindo Salgado

1 0

PEP 563 and Python 3.10.
by Thomas Wouters 21 Apr '21

21 Apr '21

(Starting a new thread so as not to derail any of the ongoing discussions.) Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP 563 (postponed evaluation of annotations) becoming the default. The Steering Council has considered the issue carefully, along with many of the proposed alternatives and solutions, and we’ve decided that at this point, we simply can’t risk the compatibility breakage of PEP 563. We need to roll back the change that made stringified annotations the default, at least for 3.10. (Pablo is already working on this.) To be clear, we are not reverting PEP 563 itself. The future import will keep working like it did since Python 3.7. We’re delaying making PEP 563 string-based annotations the default until Python 3.11. This will give us time to find a solution that works for everyone (or to find a feasible upgrade path for users who currently rely on evaluated annotations). Some considerations that led us to this decision: - PEP 563’s default change is clearly too disruptive to downstream users and third-party libraries to happen right now. We can’t risk breaking even a small subset of the FastAPI/pydantic users, not to mention other uses of evaluated type annotations that we’re not aware of yet. - PEP 563 provides no warning to users of the feature it’s disabling. Without that, we can’t expect users to be aware of the upcoming breakage. The lack of a warning was by design, and made sense in a world where type annotations were only consumed by static type checkers --- but that’s not actually the situation we’re in. There are clearly existing real-world, run-time uses of type annotations that would be adversely affected by this change. - Originally, PEP 563 was scheduled to take effect in Python 4, and this changed recently (after the discussion in the Language Summit of 2020). It's possible that third-party libraries and users didn’t plan to react in the current time frame as they were not aware of this change in timing. - There isn’t enough time to properly discuss PEP 649 or any of the alternatives before the beta 1 deadline, and we really need to make sure we don’t compound errors here. We need to look for a long term solution, which isn’t possible while still maintaining the release deadlines of Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. In the Steering Council’s unanimous opinion, rolling back the default flip for stringified annotations in Python 3.10 is the least disruptive of all the options. We need to continue discussing the issue and potential solutions, since this merely postpones the problem until 3.11. (For the record, postponing the change further is not off the table, either, for example if the final decision is to treat evaluated annotations as a deprecated feature, with warnings on use.) For what it’s worth, the SC is also considering what we can do to reduce the odds of something like this happening again, but that’s a separate consideration, and a multi-faceted one at that. For the Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

9 13

[Release manager team communication] 3.10 feature freeze is 2 weeks away
by Pablo Galindo Salgado 19 Apr '21

19 Apr '21

Hi everyone, This is a friendly reminder from the release manager team that Python 3.10 feature freeze is two weeks away (Monday, 3 May 2021). Please, be aware of the following: * No new features or improvements should be merged after feature freeze. From the devguide (https://devguide.python.org/devcycle/#beta) : > After a first beta release is published, no new features are accepted. Only bug fixes can now be committed. This is when core developers should > concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta release * If your change involves some platform-specific behaviour or has a non-trivial amount of C code, make sure you run the buildbots in your Pull Request by using the "test-with-buildbots" label ( https://discuss.python.org/t/now-you-can-test-a-pr-with-the-buildbots-befor… ). Alternatively you could check the buildbots post-merge in the buildbot server: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Bstable This is very important because if problems are detected at the time of the release, the release management team may have to revert the changes and therefore those will not be included in Python 3.10. * The master branch will be renamed to main (check our previous communication about how this will be done and how you should proceed: https://mail.python.org/archives/list/python-dev@python.org/thread/QWW7KGBW… ) If you have any questions or concerns, please contact me as soon as possible. Regards from sunny London, Pablo Galindo Salgado

1 0

How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?
by Victor Stinner 16 Apr '21

16 Apr '21

Hi, I'm getting more and more email notifications when a commit contains my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By: @vstinner". The issue is that it's not only commits from the python/cpython GitHub project, but also on all forks of the python project. Example: https://github.com/zooba/cpython/commit/9a5e643483578c3a944ceb5aa511d6c2428… "You are receiving this because you were mentioned." Some email headers: --------- From: Anthony Sottile <notifications(a)github.com> To: "zooba/cpython" <cpython(a)noreply.github.com> Cc: Victor Stinner <vstinner(a)python.org>, Mention <mention(a)noreply.github.com> Reply-To: "zooba/cpython" <reply+AABPMUP5SJOBYX4DLMTUTCN6PBBINEVBPLHAA72EO4(a)reply.github.com> List-ID: zooba/cpython <cpython.zooba.github.com> List-Unsubscribe: <mailto:unsub+AABPMUP5SJOBYX4DLMTUTCN6PBBINEVBPLHAA72EO4@reply.github.com>, <https://github.com/notifications/unsubscribe/AABPMUMREC2T2I5FM2JQBGLTHMDYNA…> X-GitHub-Sender: asottile X-GitHub-Recipient: vstinner X-GitHub-Reason: mention --------- I can unsubscribe from each python project fork, but more and more people are forking Python, it doesn't scale :-( In GitHub > Settings > Emails, I only see the email address used to "Receives notifications". In GitHub > Settings > Notifications, I only see a global "Notifications for all repositories, teams, or conversations you’re watching." option ("[x] Email [x] Web and Mobile"). There is no granularity to filter where I'm mentioned (PR review, issue, commit, etc.). It seems like Paul Ganssle has the same issue than me: https://twitter.com/pganssle/status/1379161385863643155 But the problem is that the "automerge" labels uses "Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement would be to use ""Automerge-Triggered-By: vstinner" syntax instead (avoid the @). Some developers put my handle in a commit message since it becomes the PR descriptor and sends ping me by email. But then my handle lands into the merged commit message, like: " @vstinner [noticed on python-dev](https://mail.python.org/archives/list/python-dev@python.org/thr… that there is no what's new or porting entry for removal of asyncio ``loop`` parameter. " " @vstinner / @corona10, would you mind reviewing this? " " The changes in this commit are all related to @vstinner's original review comments of the initial PEP 617 implementation PR. " " * Added @vstinner News " " Motivation for this PR (comment from @vstinner in bpo issue): " I'm not asking you to stop mentioning me. I'm just asking for help how to filter these notifications? Note: I'm using Gmail which only supports some filters, it doesn't support filtering on any email header. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

6 8

Steering Council Q&A.
by Thomas Wouters 12 Apr '21

12 Apr '21

As part of our PyCon US talk (which will be pre-recorded), the SC would like to have a Q&A session. Since it's pre-recorded, we figured we'd collect questions through Slido, which also lets people vote on the questions: https://app.sli.do/event/qdtzzpmd. The Slido will be open for questions and voting for a week, after which we'll do our best to answer them all. If you're unhappy using Slido I'd also be happy to take questions directly, but we would like to gauge the popularity of the questions to help us prioritise them. In any event, if there are questions we don't get to we'll try to answer them some other way, like a blog post. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

1 0

Ken Jin got the bug triage permission
by Pablo Galindo Salgado 12 Apr '21

12 Apr '21

Hi everyone, I started to mentor Ken Jin (Fidget-Spinner on Github) and I gave him bug triage permission on bpo (soon on GitHub as well) : https://github.com/python/core-workflow/issues/396 He got 39 commits merged into master: https://github.com/python/cpython/commits?author=Fidget-Spinner In a total of 48 PRs (including manual backports): https://github.com/python/cpython/pulls?q=is%3Apr+author%3AFidget-Spinner+i… He has made great progress in learning the CPython workflow, CPython internals and how to keep things maintainable and backwards compatible so I decided to give him bug triage permission. I will continue mentoring him and I will send him instructions on how to triage bugs and links to the relevant sections of the devguide. I ask him to ask me before closing bugs for the first weeks. Congrats Ken Jin ✨ 🍰 ✨! Regards from sunny London, Pablo Galindo Salgado

4 3