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.
Wow! A release on a Saturday? Do the release management team even rest? You
better believe it, because this is the last of the planned beta releases.
This means that the next pre-release will be the first release candidate of
Python 3.10.0. Remember that our goal is to have no ABI changes after this
beta and a few code changes as possible after 3.10.0rc1.
#This is a beta preview of Python 3.10
Python 3.10 is still in development. 3.10.0b4 is the fourth and last of the
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, the first release candidate of Python 3.10.0, will be
3.10.0rc1. It is currently scheduled for Monday, 2021-08-02.
#And now for something completely different
In quantum physics, the spin is an intrinsic form of angular momentum
carried by elementary particles, composite particles, and atomic nuclei.
The spin is one of two types of angular momentum in quantum mechanics, the
other being orbital angular momentum. The orbital angular momentum operator
is the quantum-mechanical counterpart to the classical angular momentum of
orbital revolution and appears when there is periodic structure to its
wavefunction as the angle varies. For photons, spin is the
quantum-mechanical counterpart of the polarization of light; for electrons,
the spin has no classical counterpart.
# 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
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