An abbreviated Steering Council (Emily and Thomas) met with Łukasz, the Developer-in-Residence, and discussed:
The process and requirements for enforcing PR reviews and decided to enforce reviews on PRs that are labeled as features. If you don’t want a review, add the ci:skip-review label.
The status of the Deputy DiR hiring and interview process.
Updates to the CLA bot, which are almost complete.
The Steering Council had an abbreviated meeting today, Pablo was traveling and Emily had jury duty.
The SC met with Łukasz, the Developer-in-Residence, and discussed:
Next steps from our discussions and external discussions regarding dtrace.
Requiring code review on PRs. The implementation for requiring code reviews seems doable.
Hiring for the Deputy DiR position.
The SC discussed budget and resources for mentoring support for core developers.
The SC discussed the Core Developer Sprint in Brno, including hotel bookings and financial support for attendance.
The SC discussed using Plausible for docs.python.org. The original test worked well and the WG would like to move forward with this. Costs for using the hosted version will be researched before a final decision is made, though hosted is preferred over self-hosted.
The Steering Council met with Łukasz, the Developer-in-Residence, and discussed:
The status of hiring for the Deputy DiR position.
Fixes for the CLA bot, which have been deployed.
The status of the 3.11 release; this is being held for the CVE in SSL.
The status of the code review requirement implementation for GitHub; this is next on his list.
The SC discussed the Core Developer Sprint in Brno to ensure that people can receive financial support if needed even if deadlines for responses are tight.
The Steering Council discussed the status of hiring for the Deputy Developer in Residence position and began reviewing the final list of candidates.
The SC checked in on the status of 2FA for GitHub. There is still an outstanding bot that needs to be updated for compliance. Some organizations have had the 2FA requirement automatically rolled out with a 4-week notice, which should be plenty of time if it hits before we’re ready.
If the PSF is asked “Is Python memory safe? We accept proposals seeking funds for memory safe language improvement or adoption projects.” kinds of questions how do we respond?
In general we think “yes” - but there are of course caveats(*) - I don’t think there was an official govt definition of what the term “memory safe” actually meant (that we saw - this was a brief high level conversation with limited background info).
(*) ie: We’re written in C, we allow C extensions, things like ctypes and cffi also exist. Occasionally we thus will have known and unknown bugs related to memory issues where our internal implementation needs work - but they’re rare as opposed to any language that allows pointers and equivalents. We also link against several critical common C libraries that have suffered their own problems, which thus become ours, repeatedly over the years (zlib, OpenSSL, etc). Beyond that we’ve always aimed to be memory safe as a language in that pure Python code is not supposed to have any natural way to scribble all over things and corrupt memory or program state. We’ll obviously never attempt to be a formally proven thing (like Rust leans strongly towards being regardless of whether it achieves that or not…). I doubt turtles all the way down arguments are what they intend but there hasn’t been anyone seeking to clarify that and it likely wouldn’t happen within an SC meeting context anyways.
It was a pretty brief conversation. It isn’t really SC specific, we were just convenient to ask for a litmus test. It’s more of a PSF thing.
As folks may know, I work for the US Government and I know the folks working on the RFI. You’re right that there’s no published definition of memory safety (though I think my blog post is great Defining the memory safe problem · Alex Gaynor) – but it’s clear to me that Python code is memory safe, and also often relies on code written in unsafe languages.
But also, I’m a big advocate for things like “writing extension modules in Rust”, so if there’s appetite for questions like “What would it look like for that to be officially supported, alongside the C-API”, I would be very interested.
MemHive is @yselivanov’s immutable mapping that can be shared between interpreters, including nested mappings. It is based on HAMT so it allows for cheap modification resource-wise. The tricky bit at the sprint was making sure we hold onto the references to the mapping for as long as any thread is looking at it.