Mailman 3 July 2018 - python-committers

3.4.9rc1 and 3.5.6rc1 slipping by one day to Thursday July 19 2018
by Larry Hastings 19 Jul '18

19 Jul '18

I was working with Serhiy on fixing the documentation for some bytecodes in 3.5 (GH-8338) and time got away from me. They'll both be out later today, Thursday July 19 2018. *yawn,* //arry/

1 0

Transfer of power
by Guido van Rossum 17 Jul '18

17 Jul '18

Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions. I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people -- possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own. After all that's eventually going to happen regardless -- there's still that bus lurking around the corner, and I'm not getting younger... (I'll spare you the list of medical issues.) I am not going to appoint a successor. So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation? I'm not worried about the day to day decisions in the issue tracker or on GitHub. Very rarely I get asked for an opinion, and usually it's not actually important. So this can just be dealt with as it has always been. The decisions that most matter are probably - How are PEPs decided - How are new core devs inducted We may be able to write up processes for these things as PEPs (maybe those PEPs will form a kind of constitution). But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves. Note that there's still the CoC -- if you don't like that document your only option might be to leave this group voluntarily. Perhaps there are issues to decide like when should someone be kicked out (this could be banning people from python-dev or python-ideas too, since those are also covered by the CoC). Finally. A reminder that the archives of this list are public ( https://mail.python.org/pipermail/python-committers/) although membership is closed (limited to core devs). I'll still be here, but I'm trying to let you all figure something out for yourselves. I'm tired, and need a very long break. -- --Guido van Rossum (python.org/~guido)

41 108

Summarizing our discussion about Governance
by Carol Willing 15 Jul '18

15 Jul '18

Hi folks, There have been lots of good comments the past few days. For those who are interested, I've compiled a Markdown document that pulls out and summarizes many comments. The document builds around the questions/issues that Guido posed in his message. We've been using Hackmd for collaborative writing for Project Jupyter for a while. It's similar to etherpad but with some additional versioning - if you have a GitHub account you can authenticate to make edits. This is a working document so please feel free to make edits. If you are adding content, please keep it brief and try to avoid personal names or attributions to yourself or others. As this is a gathering of information, the source of the information is less important than the information itself. https://hackmd.io/s/BJPaxUFX7 <https://hackmd.io/s/BJPaxUFX7> To view: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?view <https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?view> To edit: https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?edit <https://hackmd.io/wbBNRoOkS8ahyWA7ZwlZbg?edit> Note: I got about 80% through the messages on python-committers, but need to travel now. Will add the rest tomorrow or others please feel free to do so (I left off with Barry's July 12 14:53:18 message. Carol ‌Carol Willing‌ Research Software Engineer Project Jupyter at Cal Poly State University, San Luis Obispo @willingc on GitHub and @willingcarol on Twitter Signature Strengths Empathy - Relator - Ideation - Strategic - Learner

1 0

PEP stewardship delegation: the minimal change approach
by Nick Coghlan 14 Jul '18

14 Jul '18

Hi folks, While I think the threads suggesting that we treat Guido's retirement as an opportunity to conduct a critical self-review of our community governance structures and practices are an excellent idea, I also want to note that there's only a relatively minimal change required to PEP 1 to permit changes to proceed in areas that would likely previously have been handled by a BDFL-Delegate anyway. The gist is that both PEP 1 and the derived process I set up for PyPA allow for folks to *volunteer* as BDFL-Delegates for a PEP, rather than waiting for Guido (or the default BDFL-Delegate in the PyPA case) to pick someone. (The unwritten addendum to both these clauses is that PEP authors may also ask core devs with suitable experience to consider volunteering as BDFL-Delegate) Quoting the relevant paragraph from PEP 1 [1]: ===================== The final authority for PEP approval is the BDFL. However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. This process happens most frequently with PEPs where the BDFL has granted in principle approval for something to be done, but there are details that need to be worked out before the PEP can be accepted. ===================== And the relevant section from the PyPA process documentation [2]: ===================== Whenever a new PEP is put forward on distutils-sig, any PyPA core reviewer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL’s delegate (or “PEP czar”) for that PEP. If their self-nomination is accepted by the other PyPA core reviewers, the lead PyPI maintainer and the default BDFL delegate for package distribution metadata PEPs, then they will have the authority to approve (or reject) that PEP. Otherwise, the default BDFL-Delegate depends on the area the PEP affects. - Package Distribution Metadata PEPs: Paul Moore - Package Index Interface PEPs: Donald Stufft For Package Distribution Metadata, the default BDFL-Delegate was originally appointed directly by Guido van Rossum as Python’s BDFL (hence the use of the term BDFL-Delegate), but is now nominated by the previous default BDFL-Delegate (and the transfer of delegation approved by Guido). For Package Index Interfaces, the default responsible decision maker is the lead maintainer for the Python Package Index. ===================== So stealing Brett's excellent suggestion of "Design Steward" as a BDFL-independent term for the current BDFL-Delegate role, a potential PEP 1 amendment for the appointment process would be: ===================== Whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the "Design Steward" for that PEP. If their self-nomination is accepted by the other core developers, then they will have the authority to approve (or reject) that PEP. ===================== This is similar to the "any core developer can approve a commit, any other core developer can subsequently ask for that commit to be reverted" principle that applies for smaller changes, just applied in advance to more complex design reviews and decisions. The PyPA amendment would be similar - replacing "BDFL-Delegate" with "Design Steward", and removing any references to Guido's previously priviliged role in the process. There are some proposals where I wouldn't expect this simple modification to be sufficient (e.g. PEP 505's proposal for new None-aware operators, or PEP 572's assignment expressions), due to a lack of core developers that would consider themselves suitably experienced to be solely responsible for language level design decisions of that magnitude. However, I'd expect it to be sufficient in cases where the main motivation for requiring a PEP is due to a generally supported change's design complexity, rather than due to it being a particularly controversial decision on whether or not to do anything at all. Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0001/#pep-review-resolution [2] https://www.pypa.io/en/latest/specifications/#proposing-new-specifications -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 2

Identify roles of the BDFL
by Victor Stinner 14 Jul '18

14 Jul '18

Hi, 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya <mariatta.wijaya(a)gmail.com>: > What is the role of the successor(s)? Do we assume "whatever Guido did", or > is this an opportunity to come up with a new process? > > One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession > planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8 > The slides: > https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-p… > > Some ideas from that talk: > 1. identify critical roles (e.g. PEP decision making) > 2. refactor large roles > 3. mentor the new successor, shadow the previous leader > 4. document all the things I liked this talk! (I attended it at FOSDEM) To be able to replace the BDFL, IMHO first we need to define what are the roles of the BDFL. I also think that it's an opportunity to split the big central BDFL role into sub-roles: delegate some roles to multiple people. Let me try to list roles of the BDFL: * Take a decision/PEP. For a Python change (usually a PEP), when they are two good solutions and we fail to find a consensus, the BDFL chooses his favorite solution. Usually, when the BDFL pronounces, everybody has to follow his choice. * PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL final decision only comes after weeks of discussions and when there is already a kind of consensus (usually in favor of the PEP, otherwise the PEP is abandonned earlier). For example, python-ideas list already works well to reject ideas which should obviously be rejected for whatever reason. Sometimes when the consensus is to reject the PEP, the BDFL officially rejects it. * Public Relations. The BDFL is our reference for the Public Relations. We like to ask our BDFL what is his vision for the next 5 years, even if he usually say that he doesn't know and he is usually not the one who propose new ideas :-) * Community? In case of conflict between two developers, sometimes the BDFL tries to solve the conflict. I'm not sure that it's an official role of the BDFL :-) * Community. (Here I will maybe speak for myself.) The BDFL is my reference for the right level of humour and right level of tone (on mailing lists and other medias). When the tone goes bad, sometimes the BDFL speaks up to cool down the discussion. * Language. The BDFL is our designer for the Python language. I would like to generalize this definition to the general "taste" of Python: the BDFL defines what is "pythonic" or not by blessing some coding styles and blessing some new syntaxes. It's wider than just the pure grammar of the language. * Diversity. Last years, the BDFL was a strong player to enhance the diversity of core developers and contributors by mentoring directly Mariatta Wijaya, and suggesting regularly to mentor more people from minorities whenever possible. He also likes to wear PyLadies t-shirt and support DjangoGirls ;-) Maybe it would also help if we list what the BDFL is not: * The BDFL is no longer the technical reference to review implementation changes. IMHO other people took this role somewhere between Python 1.0 and Python 3.7. As it has been said in the other thread, there are known experts in some areas of the Python which requires specific skills. For example, Yury Selivanov is my reference for asyncio. Well, that's a bad example, since Guido van Rossum ("as a developer, not as the BDFL") is my second reference here :-) * IMHO the BDFL is not the single one to decide to promote a contributor as a core developer. It seems like our process using a vote on python-committers works. I'm not sure that the process is perfect, but at least, I don't see the BDFL here as the central key to take a decision. These list are likely incomplete, don't hesitate to complete them :-) The question is now if a single people or a single small group of people should get all these roles? Or if we can distribute these roles to multiple people? Moreover, do all these tasks still need a BDFL? For example, do we need a diversity BDFL? IMHO the most critical roles of the BDFL is to design the language and take decisions on PEPs. To follow Vicky's talk, the second step is: "2. refactor large roles". Should we split the role "take the final decision on PEPs" into sub-roles for example? Do we need in advance to define BDFL-delegate for some kinds of PEPs? Or the BDFL should define per-PEP, which ones he doesn't want to handle and need a BDFL-delegate? In my experience, the BDFL delegation was done naturally, was not the source of conflict, and usually discussed directly with the BDFL. -- By the way, I already started to work on "1. identify critical roles (e.g. PEP decision making)" a few months ago, not directly for the BDFL roles, but more generally on "maintenance tasks" and what are the key responsibilities in Python: http://pythondev.readthedocs.io/maintenance_tasks.html Victor

5 9

possible future PEP discussion format [was: Transfer of power]
by Ethan Furman 14 Jul '18

14 Jul '18

On 07/12/2018 01:27 PM, Raymond Hettinger wrote: > For the bigger decisions (and there aren't many coming up), I have some > suggestions on ways to improve the discussions so that the interested > parties can have a more equal say in the outcome and so that the > discussions can be more time efficient (it takes too much time to keep-up > with long-running, active threads). > > Essentially the idea would be have a wiki/faq editable by all the > participants. It would include the key examples, arguments for and against, > and rebuttals which can be collected into a current-state-of-the-conversation. > This would be somewhat different than the current PEP process because > currently PEP authors dominate the conversation and others can get drowned > out too easily. (This idea is modeled on the California Legislative Analyst > Voters Guide which summarizes proposals and has statements and rebuttals from > both proponents and opponents). I really like this idea. I stopped reading the PEP 572 threads once it was painfully obvious that almost all new replies were just saying the same things over and over and over... -- ~Ethan~

3 2

A different way to focus discussions
by Guido van Rossum 11 Jul '18

11 Jul '18

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-) I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes. This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion. PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo). Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic. Thoughts? (We can dogfood this proposal too, if there's interest. :-) -- --Guido van Rossum (python.org/~guido)

14 30

Time for 3.4.9 and 3.5.6
by Larry Hastings 08 Jul '18

08 Jul '18

My six-month cadence means it's time for the next releases of 3.4 and 3.5. There haven't been many changes since the last releases--two, to be exact. These two security fixes were backported to both 3.4 and 3.5: * bpo-32981: Fix catastrophic backtracking vulns (GH-5955) * bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) 3.5 also got some doc-only changes related to the online "version switcher" dropdown. (They weren't backported to 3.4 because we don't list 3.4 in the version switcher dropdown anymore.) There are currently no PRs open for either 3.4 or 3.5, and they also have no open "release blocker" or "deferred blocker" bugs. It seems things are pretty quiet in our two security-fixes-only branches--a good way to be! I therefore propose to cut the RCs in a week and a half, and the finals two weeks later. So: Wednesday July 18 2018 - 3.4.9rc1 and 3.5.6rc1 Wednesday August 1 2018 - 3.4.9 final and 3.5.6 final If anybody needs more time I'm totally happy to accommodate them--you can probably have all the time you need. I'm trying to keep to my rough six-month cadence, but honestly that's pretty arbitrary. Thanks to all of you who keep making 3.4 and 3.5 better, //arry/

3 4

Please be patient
by Guido van Rossum 06 Jul '18

06 Jul '18

I have been overwhelmed by the amount of feedback I've received on PEP 572. I can't possibly respond to everything, and some of the feedback just takes time. E.g. I am planning to do a revision of the PEP for clarity, but this will take some time, and I may not get to it until next week or the week after. There are also several minor TODOs in the PEP that need to be resolved. I will sort it all out, just please be patient. -- --Guido van Rossum (python.org/~guido)

1 0

Vote to promote Pablo Salingo Salgado as core developer
by Victor Stinner 03 Jul '18

03 Jul '18

Hi, I propose to promote Pablo Salingo Salgado as a core developer and so open a vote during one week. If there is no strong opposition, I will promote him but also continue to mentor him for a least one month. Pablo is contributing frequently to Python since almost one year. He added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to Python 3.8. I am now waiting for his os.copy_file_range() function! (Others are working on it.) https://bugs.python.org/issue26826 I am mentoring Pablo Salingo Salgado since January. I am watching his hard work since last September. He made many non trivial and useful contributions to Python. I think that he understands well how Python is developed, is respectful, try to find answers alone before asking, and is eager to learn. In case of doubt, he ask others before doing something, like closing an issue. I trust that Pablo will respect opinions of others, like not merging a PR if someone disagree. Pablo's merged PR: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Ap… He got 22 commits merged into master between September 2017 and June 2018. If Pablo is promoted as a core developer, I propose to continue to be his mentor for at least one month, and ask him before merging any PR. Note: Pablo already has the bug triage permission for 5 months: https://mail.python.org/pipermail/python-committers/2018-January/005133.html Victor

11 25