Hi,
Python 3.5 entered security fix only mode. Should we now remove the
"needs backport to 3.5" label? Other security only branches don't have
this label neither (3.3 and 3.4).
Victor
https://discuss.python.org/t/vote-on-pep-13-change-to-specify-voting-time-f…
Summary: one week to vote for new core devs, two weeks for PEP 13 changes
(which is how long I set the vote on Discourse to be open for). This change
is approved by the steering council.
And as a reminder, changes to PEP 13 require a 2/3 approval by voters.
I've posted an update from the Steering Council to our repo:
https://github.com/python/steering-council/blob/master/updates/2019-04-26_s…
I will also link to this on python-dev and on Discourse (discuss.python.org
).
For completeness, below is the full text.
# Steering Council Update
Date: 2019-04-26
Steering Council updates will be posted irregularly and as needed.
We strive to post at least once every month. We provide these updates
to foster open and transparent communication about Steering Council
activity.
## Message from the Steering Council
Sorry we've been silent for a while! We've all been swamped with
work, but we've been meeting regularly. Below are some of the
outcomes of our conversations. Many of you will be happy to hear that
we've cleared the backlog of PEPs by assigning BDFL-Delegates to
almost all outstanding PEPs. We're also appearing at PyCon US.
---
## Mandate
This section organizes Steering Council (SC) activity and projects
using the mandates listed in PEP 13.
### Language
> Maintain the quality and stability of the Python language and CPython
interpreter
- We've begun to explore the options for improving the interpreter in
the future, but apart from the PEP work detailed below we've not come to
any
conclusions yet. In the coming months we hope to come up with
guidelines and a process for evolving the interpreter, to be
developed in close participation with the core developers and
representatives of various user bases.
### Contributors
> Make contributing as accessible, inclusive, and sustainable as possible
- **Communications channels:** We have an array of communication
options, depending on the context.
- To reach core committers specifically, we will use
python-committers(a)python.org.
- To reach the entire Python developer community, we will use
python-dev(a)python.org.
- For specific requests to the SC, please use
the public GitHub tracker at
https://github.com/python/steering-council/issues.
- To reach just the SC, you can email us at
steering-council(a)python.org.
- We will also occasionally use Discourse, at
https://discuss.python.org (for example, Discourse is useful for
polls and votes).
- **Issue tracker:** We've discussed PEP 581, "Using GitHub Issues for
CPython" by Mariatta Wijaya. We're in favor of this move, and feel
that the transition should be professionally planned and executed.
In collaboration with the PSF we're exploring ideas on how to do
that (using the successful roll-out of the new Warehouse
infrastructure for PyPI as a model).
### PEPs
> Establish appropriate decision-making processes for PEPs
- To request a PEP review, please file an issue on the
[SC issue tracker](https://github.com/python/steering-council/issues).
- We've appointed BDFL-Delegates (BDs) to a number of PEPs, after
ensuring that the proposed BD and the PEP author(s) agree on the
appointment:
- PEP 558 "Defined semantics for locals()", Nick Coghlan.
*Appointed Nathaniel J. Smith as BD.*
- PEP 497, "A standard mechanism for backward compatibility", Ed
Schofield.
*Appointed Brett Cannon as BD on behalf of the SC.*
- PEP 387 "Backwards Compatibility Policy", Benjamin Peterson.
*Appointed Brett Cannon as BD on behalf of the SC.*
- PEP 554, "Multiple Interpreters in the Stdlib", Eric Snow.
*Appointed Antoine Pitrou as BD.* (BD and author have indicated
that this PEP will be postponed until Python 3.9.)
- PEP 586, PEP 589, PEP 591 (various typing PEPs by members of the
mypy team and others, topics Literal, TypedDict, and Final).
*Appointed Guido van Rossum as BD.* (PEP 544, Protocols, also
belongs in this list; Guido made himself BD last year.)
- PEP 578, "Python Runtime Audit Hooks", Steve Dower.
*Appointed Christian Heimes as BD.*
- PEPs 576, 579, 580, 590 (competing PEPs on C function call
optimizations by Mark Shannon and Jeroen Demeyer; note that PEP
576 is withdrawn in favor of PEP 590).
*Appointed Petr Viktorin as BD.*
- PEP 533, "Deterministic cleanup for iterators", Nathaniel J. Smith.
*Appointed Yury Selivanov as BD.*
- PEP 570, "Python Positional-Only Parameters", by Larry Hastings,
Pablo Galindo and others.
*Appointed Guido van Rossum as BD.* (And he approved it!)
- PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou.
*Appointed Nick Coghlan as BD.*
- PEP 573, "Module State Access from C Extension Methods", Petr
Viktorin and others.
*Postponed to Python 3.9. Appointed Stefan Behnel as BD.*
- And we've updated the status of some other PEPs:
- PEP 557 "Data Classes", Eric V Smith. *Marked Final.*
- PEP 467 "Minor API improvements for binary sequences", Nick
Coghlan, Ethan Furman. *Deferred.*
### Interaction with PSF
> Formalize and maintain the relationship between the core team and the PSF
- The PSF Code of Conduct Workgroup is working on a revision of the CoC.
Brett and Carol
serve on the Workgroup.
- We've agreed to a panel discussion at PyCon US in Cleveland, Sunday
morning May 5th between 9:20am and 10:00am.
### Governance
> Seek consensus among contributors and the core team before acting in a
formal capacity,
> Act as a "court of final appeal" for decisions where all other methods
have failed.
- Established a weekly SC meeting cadence (Tuesdays 3-4pm US West Coast
time).
- We proposed two updates to PEP 13, setting the voting period for new
core devs to one week and for PEP 13 changes to two weeks.
The vote is still ongoing on Discourse:
https://discuss.python.org/t/vote-on-pep-13-change-to-specify-voting-time-f…
---
## Reference
This reference section summarizes the Steering Council's mandate and powers.
### Mandate (PEP 13)
The steering council shall work to:
- Maintain the quality and stability of the Python language and
CPython interpreter,
- Make contributing as accessible, inclusive, and sustainable as
possible,
- Formalize and maintain the relationship between the core team and
the PSF,
- Establish appropriate decision-making processes for PEPs,
- Seek consensus among contributors and the core team before acting in
a formal capacity,
- Act as a "court of final appeal" for decisions where all other
methods have failed.
### Powers (PEP 13)
The council has broad authority to make decisions about the project.
For example, they can:
- Accept or reject PEPs
- Enforce or update the project's code of conduct
- Work with the PSF to manage any project assets
- Delegate parts of their authority to other subcommittees or
processes
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>
Hello everyone,
Thank you. It's just a dream come true. When I started to contribute to
Python, I didn't think I would become a core-dev. I am really honoured
becoming a member of this famous team.
I know there were counter-votes during the poll and I understand them.
I will do so with extra care so nobody will be disappointed for this
decision. If you want to send me your vote in private, please do
it, I love to improve.
Now, I will continue to work with Victor and Julien and you.
For example, improving the documentation and the mentoring for the new
contributors and certainly to become an expert of some modules.
As a final note, I would like to thank Victor and Julien for their
trust and the encouragement in this process.
PS: The vote was really stressing because I was at PyCon SK
during the process, without my family and my friends.
Sorry for my late introduction, I was on holiday.
Have a nice day and hope see you at PyCon US in 2 weeks.
Cheers,
Stéphane
--
Stéphane Wirtel - https://wirtel.be - @matrixise
Hi,
Stéphane Wirtel has been promoted as a core developer: Welcome aboard
Stéphane 🎉! I asked him to introduce himself on the
python-committers, but he is currently in holiday (and I am not sure
that he is subscribed to the list yet).
The Steering Committee approved the promotion, but asked Julien and me
(who proposed Stéphane) to extend the mentoring period to 2 mentors.
Julien and me are fine with that, we already planned to decide
together when Stéphane will be fully confident with his new
responsibilities.
Julien Palard and me (Victor Stinner) will mentor him “strictly” for
at least 2 months: Stéphane will have to ask us before merging a pull
request. We plan to discuss together to decide when the strict
mentoring ends. Right now, we are updating everything to make Stéphane
Wirtel officially a core dev.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
I propose to promote Stefan Behnel (aka scoder on the tracker and
GitHub) as a core developer. Perhaps not one from us is surprised that
he is not yet a core developer. Stefan is a core developer of Cython and
lxml, two important projects in Python ecosystem. He is a coauthor of
PEP 489. His first patch is dated by 2010. He is not so active as other
candidates in writing patches (I have counted less than 20 of his
commits), but he is active on the bug tracker and mailing lists
(reported 95 issues and commented much more). His expertise in
XML-related issues was very important. He is assigned as an expert for
the xml.etree package.
Maybe you can add more about Stefan's merits. This is just what I know
personally. I worked a much with him and have very good impression about
him.
Ah, and the PSF also just granted him their quarterly community service
award for
2019-Q1. https://www.python.org/community/awards/psf-awards/#march-2019
