steering-council

Aside from what's publicly visible on the Discourse forum in the PSF and Committers sections (https://discuss.python.org/c/python-software-foundation/9 and https://discuss.python.org/c/committers/5 respectively) I'm not aware of any formal statements, unless perhaps you count Steering Council updates (https://github.com/python/steering-council). The PSF runs a blog at https://pyfound.blogspot.com/, but I see nothing substantial there there isn't entirely redundant (e.g. a copy-paste of the "Python’s Supportive and Welcoming Environment is Tightly Coupled to Its Progress" letter). I have seen commentary by a few of them on social media - mostly, per my impression, vague expressions of annoyance at the stress supposedly caused by Code of Conduct enforcement (note that in the post announcing my ban, Mr. Langa disclosed an unusually high rece

Very exciting. Sam Gross took a very bold move with his "I don't need a yes/no right now, but I do need to know what acceptance looks like, and this issue has been languishing." [0] That interaction could have gone a lot of different ways (especially as a neurospicy engineer myself and knowing the overall spice level in the computer world) but it sounds like that was the exact kick the council needed. It is still a long and winding path (double-digit engineer-years) to get a no-gil python, but at least there exists a proper path from the looks of it. The hardest part by far will be ensuring the correctness of all existing codebases. It's one thing to say you don't want a 2->3 repeat. It's another altogether if you were to claim no breaking changes, but fear of bugs resulted in folks avoiding the upgrade in practice. Making gil/no-gil even

> If PEP 703 is accepted, Meta can commit to support […] between the acceptance of PEP 703 and the end of 2025 Meanwhile, the Steering Council is dragging their feet, even though so many people in the community have chimed in their support for nogil being a thing (in the linked thread and two others). https://github.com/python/steering-council/issues/188#issuec...

GVR called it a fork two weeks ago in his justification for not accepting it [1]. If that surprises you, the backstory is summarized pretty well in the article [2] and FAQ [3]. I'm really not trying to be secretive. We can debate whatever you want, but we have to at least acknowledge CPython's stated position. [1] https://github.com/python/steering-council/issues/188#issuec... [2] https://www.artima.com/weblogs/viewpost.jsp?thread=214235 [3] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...

from the PEP author Sam Gross: Hi Gregory and the Steering Council, Thanks for reviewing the PEP. The PEP was posted five months ago, and it has been 20 months since an end-to-end working implementation (that works with a large number of extensions) was discussed on python-dev. I appreciate everyone who has taken the time to review the PEP and offer comments and suggestions. You wrote that the Steering Council's decision does not mean "no," but the steering council has not set a bar for acceptance, stated what evidence is actually needed, nor said when a final decision will be made. Given the expressed demand for PEP 703, it makes sense to me for the steering committee to develop a timeline for identifying the factors it may need to consider and for determining the steps that would be required for the change to happen smoothly. Without th

> The Python Steering Council discussed this and we agree that even if it was easy to edit post-merge we would still leave the message as-is; we do not deplore the message. > We also agree that commit messages are meant to convey the reasons why a change was made. > We can't say whether we would have halted, edited, or done anything else to change the submission of the commit message. https://github.com/python/steering-council/issues/34#issueco...