As you might know, PEP 581 (Using GitHub Issues for CPython) has been
approved. I've been working with Ewa, Ee, the Working Group, the
Steering Council, and the GitHub folks to make this happen, and the SC
encouraged me to give you all a quick update.
This effort is being tracked at
<https://github.com/psf/gh-migration/projects/1>: this board reflects
the current status of the project. The PEPs (including PEP 588 --
GitHub Issues Migration Plan) haven't been updated yet and might
contain outdated information, so please refer to the psf/gh-migration
repo for the latest updates.
During the next phase I will work with the WG to sort out all the
major issues that we might encounter, and then I will once again reach
out to you to gather feedback from the wider audience that follows
these mailing lists.
Through a collaboration, the PSF and SC scoped the role for a
Developer-in-Residence. We are now accepting resumes -- see below for
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
The Python Steering Council and the Python Software Foundation are looking
to hire a Developer-in-Residence!
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.
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
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)
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.
I have discovered someone tried to break into my GitHub account (you can
check yourself by going to https://github.com/settings/security-log and
looking for "failed to login" attempts for potentially odd geographical
locations for yourself). CPython probably would have been the biggest
target for them had they gotten in (my work stuff is all open source and it
would have required breaking into another account). But GitHub has a
completely unique password and MFA turned on, so they were unsuccessful.
Please make sure you have a unique password for your GitHub account and
that you have 2FA/MFA turned on (I honestly think we should start requiring
this; I'm sure we can get money for folks to get security keys). Other
languages like PHP have been successfully hacked (
so this isn't a hypothetical anymore that we would be targets for folks who
want to install a backdoor into one of the world's most popular programming
languages and is now mission-critical for a lot of massive corporations and
I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in Tracebacks) has been unanimously accepted for Python 3.11 by the Python Steering Council.
Congratulations Pablo, Batuhan, and Ammar!
-Barry (on behalf of the Steering Council)
I haven't bisected the Python source tree in a long time and it seems
our current way of making releases is messing it up.
# Start on tip of branch 3.9
(3.9)$ git bisect start
# 3.9 tip is good
(3.9|BISECTING)$ git bisect good
# Switch to release 3.9.1, where the bug wasn't fixed yet
(3.9|BISECTING)$ git checkout v3.9.1
((v3.9.1)|BISECTING)$ LANG=C git bisect bad
Some good revs are not ancestors of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistook good and bad revs?
How can this be worked around? Not being able to bisect a fix or
regression is really annoying.
-------- Forwarded Message --------
Subject: EuroPython 2021: Free tickets for Python Core Developers
Date: Fri, 25 Jun 2021 15:31:32 +0200
From: Marc-Andre Lemburg <mal(a)europython.eu>
Organization: EuroPython Society (EPS)
To: Python List <python-list(a)python.org>
In 2019, we have set up the Guido van Rossum Core Developer Grant, to
make it easy for Python Core Developers to attend EuroPython, but also
to give something back to the core team and add a perk to make core
development more attractive.
If you are a core developer, please check our grant page for details on
how to apply:
PS: If you are a core developer and want to organize a core sprint,
workshop, language summit or similar event at EuroPython 2021, please
get in touch with our program workgroup soon, so that we can help
arrange things: program(a)europython.eu
PPS: If you want to become a core developer, please have a look at the
Python Dev Guide:
EuroPython 2021 will be run online from July 26 - August 1:
- Two workshop/training days (July 26 - 27)
- Three conference days (July 28 - 30)
- Two sprint days (July 31 - August 1)
The sessions will be scheduled to ensure they are also accessible for
those in the Asian and Americas time zones.
More infos are available on our website at https://ep2021.europython.eu/
Help spread the word
Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !
Link to the blog post:
EuroPython 2021 Team
Summer is almost here (at least in half of the planet) and Python 3.10 is
finishing baking in the oven. For those of you that want to taste it before
is finally ready (and if you are a library developer, you certainly do!)
you can have the second-to-last beta now, but be careful as is still very
#This is a beta preview of Python 3.10
Python 3.10 is still in development. 3.10.0b3 is the third 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.
We strongly encourage maintainers of third-party Python projects to test
with 3.10 during the beta phase and report issues found to the Python bug
tracker 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 (Monday, 2021-08-02). Our goal is to have no ABI changes
after beta 4 and as few code changes as possible after 3.10.0rc1, the first
release candidate. To achieve that, it will be extremely important to get
as much exposure for 3.10 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.
The next pre-release of Python 3.10 will be 3.10.0b4, currently scheduled
for Saturday, 2021-07-10.
#And now for something completely different
There are no green stars. Why? In general, objects don’t emit a single
wavelength of light when they shine. Instead, they emit photons in a range
of wavelengths. If you were to use some sort of detector that is sensitive
to the wavelengths of light emitted by an object, and then plotted the
number of them versus wavelength, you get a lopsided plot called a
blackbody curve. For an object as hot as the Sun, that curve peaks at
blue-green, so it emits most of its photons there. But it still emits some
that are bluer, and some that are redder. When we look at the Sun, we see
all these colors blended together. Our eyes mix them up to produce one
color: white. A warmer star will put out more blue, and a cooler one
redder, but no matter what, our eyes just won’t see that as green. Due to
how we perceive color, the only way to see a star as being green is for it
to be only emitting green light. But as starts always emit radiation
following the blackbody curve, that’s pretty much impossible.
# We hope you enjoy those new releases!
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Regards from very cloudy London,
Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower