April/May 2022 Steering Council update

We’re behind in updates from the Steering council. To clear a bit of the backlog, here’s
April & May. These are published on the SC repo, and repeated below:


  • Discussed CPython public C APIs with leading underscores in them as in
    PEP-523 (Adding a frame evaluation API
    to CPython), for example, and the desire
    for perhaps a stable only within bugfixes API tier marked by semantics
    other than leading underscores (which should be reserved for private APIs).
    [Note from the future: this discussion later led to PEP-689
    (Unstable C API tier).]
  • As to the question of should the PEP-523 APIs stay as is? General consensus
    was “yes”. Less disruptive.
  • Discussed clarifying a backwards compatibility policy regarding things which
    have no meaningful way to provide deprecation cycle warnings.
  • Briefly discussed updates to PEP-670
    (Convert macros to functions in the Python C API).
  • Discussed PEP-678 (Enriching Exceptions
    with Notes), generally happy with the changes. Delaying pronouncement until
    after all of us have reread it.
  • Discussed PEP-681 (Data Class
    Transforms), how we’d defer that to typing-sig, and if we can generally avoid
    having the SC hold things up in delegation situations.
  • Agreed on a cut-off for new 3.11 targeting PRs not already on the SC plate,
    the time window before beta1 is too short.
  • Discussed our PyCon US keynote slot.


  • Welcomed Deb, our new PSF General Director.
  • Developer in Residence Łukasz sync:
    • Happy about a successful migration to GitHub Issues!
    • Acknowledged rough edges, prioritizing those, ex: The CLA bot.
    • Musing about other workflow friction improvement we could do.
    • Dev in Res PyCon keynote planning. Steering Council will avoid
      covering the same topic.
  • Director of Infrastructure Ee sync:
    • Discussed two factor authentication plans (2FA).
    • Noted hg.python.org & svn.python.org maintenance needs.
    • Discussed hiring another infrastructure person.
  • Discussed possible fall core sprints organization.
  • Agreed to accept PEP-678 (Enriching
    Exceptions with Notes).
  • Agreed to accept PEP-670 (Convert macros
    to functions in the Python C API).
  • Discussed PEPs that are vying for 3.11 acceptance:
    • PEP 686 (Make UTF-8 mode default),
    • PEP 687 (Isolating modules in the
      standard library),
    • PEP 659 (Specializing Adaptive
    • PEP 681 (Data Class Transforms).
  • Discussed PEP 620 (Hide implementation
    details from the C API).
  • Discussed smoothing the PEP → SC submission process: An issue template with a
    checklist is coming.
  • Discussed python-dev vs Discourse expected use; deferring until after beta1.


  • Theme: PyCon PyCon PyCon
  • Discussed if we can meet next week right before PyCon starts.
  • Discussed our Steering Council PyCon US keynote plans.
  • New Release Manager(s) for 3.12 chosen by existing RMs. Announce later.
  • Discussed the upcoming PyCon Language Summit.
  • Discussed PyCon Typing Summit attendance.
  • Discussed PEP-681 (Data Class
    Transforms), noted missing feedback from attrs. Lets make that happen.
  • Discussed PEP-686 (Make UTF-8 mode
    default), in favor with caveat of a longer deprecation timeline.
  • Discussed obsoleting the Provisional API concept.
  • Discussed tiered platform support.
  • Randomly discussed enum syntax ideas.
  • Made a lumberjack joke. It was so good this scribe forgot it.


  • Discussed GitHub Issues migration administrivia.
  • Discussed our impending PyCon keynote.
  • Discussed how most of us need to reread PEP-687.
  • Discussed what role the python-ideas mailing list has.
  • Discussed what topics we should bring up at the language summit.
  • Discussed how we’d like to see PEPs discussed.
  • Discussed release management team woes and bus factors.
  • Discussed the new C API tier again this time called “semi-stable”.
  • Discussed shoving mailcap into PEP-594
    (Removing dead batteries from the standard library): unanimous yes.
  • Missed a chance to discuss semi-sweet chocolate chip cookies.
  • Mind you, møøse bites Kan be pretty nasti.


  • SC members who attended PyCon US gave a summary of the Language Summit.
  • The SC discussed topics brought up at the Summit:
    • Removing the GIL and switching to mimalloc
    • Subinterpreters
    • WebAssembly
    • Lazy imports
    • Typing PEPs – 563 (Postponed Evaluation of Annotations)
      & 649 (Deferred Evaluation Of Annotations Using Descriptors)
    • Switching to discuss.python.org
    • Supporting core mentorship


  • 4 SC members present
  • The SC met with the Developer in Residence:
    • Łukasz reported on his PyCon keynote & upcoming talks in Lithuania & Dublin
    • Łukasz reported on issues with the new CLA bot
  • SC members who were at PyCon reported on the conference.
  • The SC discussed PEP 687 (isolating modules)
    and PEP 689 (Unstable C API tier),
    postponed decision until all members give their opinion
  • The SC discussed PEP 690 (Lazy Imports),
    though it’s not ready for the SC yet.
    • This prompted a meta-discussion: should SC members participate in PEP discussions
      (and risk being misrepresented as the voice of the SC),
      or not (and only point out issues in the SC review)?
      There are differing opinions.
      We definitely need to be careful with wording.
  • The SC discussed GIL removal.
    Many unsolved issues remain, no one seems to want to turn the
    proof of concept into PEPs and pull requests.


Meeting was skipped. Only 2 SC members could make it.


  • 3 SC members present
  • The SC met with the PSF Executive Director, Director of Infrastructure and
    the Developer-in-Residence and discussed funding security for CPython and
    the Python ecosystem, and potentially finding a project manager to help
    the Python Security Response Team mailing list.
  • The Developer-in-Residence gave the SC an update on current work.
  • The DiR, the PSF ED and the SC discussed the current state of
    the new CLA bot and the legal ramifications of the switch.
  • The SC discussed how to support mentoring by and among Core Developers with
    the Executive Director.
  • The SC discussed PEP 689 (Unstable C API tier)
  • The SC accepted PEP 687 (Isolating modules in the standard library)
  • The SC discussed improving the bus factor situation around Python releases.


  • The SC discussed PEP 689 (Unstable C API tier)
    and decided to accept it provided that the unstable API has underscore-prefixed names.
  • The SC accepted PEP 681 (Data Class Transforms).
  • The SC discussed the role and governance of the Python Security Response Team.