August/September/October 2023 Steering Council Updates

Committers
1

The August, September, and October SC updates have been posted on GitHub and are included below:

August 2023

2023-08-07

  • 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.

2023-08-14

  • 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.

2023-08-21

  • 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 SC continued to discuss PEP 703 (Making the Global Interpreter Lock Optional in CPython).

2023-08-28

  • 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.
  • The SC discussed PEP 713 (Callable Modules) and decided to reject it, as the changes are not entirely net-positive.

September 2023

2023-09-04

2023-09-11

  • The Steering Council met with Łukasz, the Developer-in-Residence, and discussed:
    • Hiring for the Deputy Developer-In-Residence role, including takeaways and next steps from the final interviews that the SC conducted.
  • The SC worked on the list of acceptance criteria for PEP 703.

2023-09-18

2023-09-25

October 2023

2023-10-02

  • The Steering Council met with Łukasz, the Developer-in-Residence, and discussed:
    • The Deputy Developer-in-Residence interviews.
    • Ongoing work around yield from in generators, as well as PEPs 667/558.
    • Ongoing work around the buildbot master, individual buildbots and how to handle non-tier-1 configurations on tier-1 platforms like AddressSanitizer.
    • How to improve buildbot health and make people more aware of breakages they are causing on buildbots.
  • The SC discussed the ongoing search for mentorship training and support.

2023-10-09

  • An abbreviated Steering Council (Thomas, Pablo, and Greg) met informally in-person at the Core Developer Sprint in Brno.

2023-10-16

  • An abbreviated Steering Council (Pablo and Brett) met with Łukasz, the Developer-in-Residence, and discussed updates on the different topics that he worked on at the sprint:
    • Coverage reports.
    • Updates of Miss-islington.
    • Help Yury with a MemHive (sharing between multiple interpreters).
    • General summary of what other people worked on.

2023-10-23

  • An abbreviated Steering Council (Thomas, Emily, and Brett) recapped the recent Core Developer Sprint.
  • The SC received a new proposal for mentorship support, which will be reviewed next week.
  • The SC discussed the final specifics for accepting PEP 703 (Making the Global Interpreter Lock Optional in CPython).
  • The SC discussed the logistics of fitting tall people into small cars.

2023-10-30

  • The Steering Council met with Łukasz, the Developer-in-Residence, and discussed:
    • Setting up buildbots for upcoming free-threading work.
    • General buildbot statuses and updates to fix buildbot slowness.
  • The SC discussed their options and logistics for hiring an external person to take meeting minutes during weekly meetings and opted to defer this decision to the next SC.
  • The SC confirmed that the details for the upcoming SC election are approved.
  • The SC discussed requests for the breaking change in the Tkinter method wm_attributes() and decided that PEP-387 (Backwards Compatibility Policy) should apply and the change should follow a proper deprecation.
8 Likes
2

Can you say a little bit more about this item?

3 Likes
3

IIRC this came up from the PSF side as they (Deb, PSF Director) were being asked questions in regards to this years recent US Government CISA focus on elevating the importance of using memory safe programming languages to push the industry towards avoid entire classes of recurring security issues.

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.

1 Like
4

Could you add some more context on what “MemHive” is ?

I tried to search for it, but this didn’t bring up any obviously matching resources, except an old announcement for PostgreSQL, which sounds vaguely related.

Many thanks.

1 Like
5

Thanks, that’s helpful!

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 :smiley: 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.

9 Likes
6

@ambv :point_up: (w/ extra characters)

7

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.

4 Likes