Mailman 3 July 2018 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

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

6 11

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 Dec '18

17 Dec '18

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 1

Organizing an informational PEP on project governance options (was Re: Transfer of power)
by Nathaniel Smith 08 Aug '18

08 Aug '18

On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa <lukasz(a)langa.pl> wrote: > I'm +1 to an Informational PEP around the state of the art in project governance. I think this is a great idea. There's a lot of experience out there on different governance models, but of course any given project only uses one of them, so knowledge about what works and what doesn't is pretty fragmented across the F/OSS community. And this is a really important decision for us and our users, so we should do due diligence. For example, we should think this through at least as carefully as we thought through Github vs. Gitlab :-). A PEP is a good format to start doing that. I volunteer to co-author such a PEP. But I'm not up to doing it on my own. So... who else wants to be a co-author? (I'm not going to pressure anyone, but Brett, Mariatta, and Carol, please know that your names were the first ones that jumped to my mind when thinking about this :-).) What I'm thinking: - While this might eventually produce some recommendations, the immediate goal would just be to collect together different options and ideas and point out their trade-offs. I'm guessing most core devs aren't interested in becoming experts on open-source governance, so the goal here would be to help the broader community get up to speed and have a more informed discussion [1]. - As per the general PEP philosophy, I think this is best done by having some amount of general discussion on python-dev/python-committers, plus a small group of coauthors (say 2-4 people) who take responsibility for filtering ideas and organizing them in a coherent document. - Places where we'll want to look for ideas: - The thread already happening on python-committers - Whatever books / articles / blog posts / etc. we can find (e.g. I know Karl Fogel's Producing OSS book has some good discussion) - Other major projects in a similar position to CPython (e.g., node.js, Rust) -- what do they do, and what parts are they happy/not-happy about? - Large Python projects (e.g. Django) -- likewise If you have suggestions for particularly interesting projects or excellent writing on the topic, then this thread would be a good place to mention them. -n [1] The NumPy project has put a lot of energy into working through governance issues over the last few years, and one thing that definitely helped was coming up with some "assigned reading" ahead of the main sprint where we talked about this. NumPy's problems are/were pretty different from CPython's, but I'm imagining this PEP as filling a similar role. -- Nathaniel J. Smith -- https://vorpus.org

8 9

Results of Pablo's promotion votes: Pablo is promoted as a core dev!
by Victor Stinner 31 Jul '18

31 Jul '18

Hi, The result of the vote to to promote Pablo Salingo Salgado as core developer after one week is positive: I declare that Pablo is now a core developer, congrats! I will follow the usual process to actually make him a core dev, and ask him to write a short introduction email to this list. But I also noted that Pablo lacks experience to be fully autonomous on merging pull requests, so I also requires that Pablo will have to be strictly mentored by me for 3 months. By strict, I mean that Pablo will have to ask me to merge any pull request. This strict mentoring may be extended depending on Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to blame me directly if anything goes wrong :-) Giving more responsibilities to Pablo is part of the learning process. Reviewing as a core developer is different than a review as a contributor: core developers are expected to actually merge a pull request once they approve the change. Merging a pull request is a big responsibility and an investment in the long-term, because the committer is expected to fix regressions and issues related to this change for next months, if not next years. Note: Cheryl Sabella has also been identified as an active contributor who may be promoted as well. I am already discussing with her about that for 1 month, but last month, Cheryl chose to wait. I will keep you in touch ;-) Vote results. Promote (+1): 8 votes * Victor Stinner * Terry Reedy * Carol Willing * Gregory P. Smith ("+0.5") * Eric Snow * Brett Cannon * Nathaniel Smith * Antoine Pitrou ("+0.5") Wait (-1): 1 vote * Berker Peksağ Neutral (0): 1 vote * Serhiy Storchaka ("-0") Victor

5 7

Mentoring Office Hours - the idea, and a question
by Brian Curtin 27 Jul '18

27 Jul '18

Hey all, At the Language Summit last week, after Mariatta's talk we had a conversation around diversity and how to grow our contributor base, which led to someone (Steve Dower?) suggesting we post a sort of "Office Hours" list. This would be a list of current core developers who are interested in being available at set time(s) for helping mentor newer contributors in our community through our process and, if they're interested, mentoring them through the process of becoming core developers themselves. This "Office Hours" concept is a type of thing that has worked well elsewhere, including around the software world, and we have some people interested in offering said mentorship, so I would like to move on to getting this list up somewhere so we can start doing it. With that said, before I go make a PR to the devguide to start iterating on the implementation, an important question: As this is both an event similar to an in-person meetup and an event meant to be a safe space for those getting started, it will explicitly mention the code of conduct. As such, it needs a person/persons/list to contact should something arise in this context that needs to be handled. What/who should that be? * Suggestion 1: use the already in-place core-mentorship-owner(a)python.org, though I can't tell who's on there. * Suggestion 2: Create some new list with a few key people on it. * Suggestion 3: List some direct names. Who? As for implementation, there are some tools out there we could possibly use, but in the interests of getting something out there I'm just going to make a table and fill in some common information, starting with my own. Calendar apps and other integrations can come as we figure them out. Brian

3 5

And Now for Something Completely Different
by Victor Stinner 25 Jul '18

25 Jul '18

or: Replace Dictatorship with Democracy. Hi, == Introduction: unjustified fears? == I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of these BD(FL) and/or council: what they are expected to do, what they cannot do, etc. It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python. Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python? In my experience, a consensus has been reached in less than one month on most PEPs without the help of the BDFL. There were a few controversal PEPs. The most controversial PEP is obviously the latest accepted PEP, the PEP 572 (assignment expressions). OK. But do you have other examples? In a different thread,I gave the example of my PEP 446 "Make newly created file descriptors non-inheritable": Guido approved it, even though Charles-François Natali was against it (since it broke the backward compatibility). If I recall correctly, the issue with that PEP is that almost nobody cared about it: it was mostly Charles-François and Guido :-) Hopefully, such cases are rare. == What is the image send to the community and contributors? == Last year, I mentored multiple contributors. What I learnt is that contributing to Python is much harder than what I expected. Most core developers are core for 5 years or longer (maybe 10 years for some of them?), and we (core developers) forgot how hard it is to contribute. When your name is known in a community: it's very easy to share your ideas, other people listen to you and respect your experience. It's much faster to get a pull request merged... sometimes simply because you merged your own PR :-) Becoming a core developer takes between 6 months and 2 years, it requires a lot of commitment, to have free time, etc. In short, it's *very hard* to recruit new core developers. It seems like many people forgot that. What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them? I'm not saying that a new governance will lead to such issues. I'm only opening the question of the image sent to the community. == Democracy: vote on PEPs open to all core developers == I would like to come back to my idea of using a vote restricted to core developers: a PEP would require "50% +1" (at least 50% of votes + 1 voter) to be approved. Maybe some more sensitive PEPs would require a bigger majority, like 66%+1, for example PEPs changing the Python language. The vote would only be opened once we (core devs) consider that the PEP is ready for a vote. Drawbacks. The main risk is that PEPs would fail to be approved if no consensus can be found. In practice, it means that Python remains unchanged. Honestly, I don't think that this consequence is a disaster: sometimes, doing nothing *is* a wise choice :-) The PEP author is free to retry in 6 or 12 months with a new PEP, maybe written differently, maybe with better examples. For example, if everybody agreed to reject the first version of the PEP 572, I expect a more positive result on the latest flavor of the PEP. The issue is sometimes the PEP itself, not the proposed change. Guido forced me to rewrite my very long PEP 540 "UTF-8 Mode" from scratch to make it shorter (and simpler), and it was a major enhancement for my PEP :-) OK, but sometimes everyone like the proposed change, but just not the PEP itself. What can be done? Well, the PEP can be modified. Another different PEP can be proposed. In the worst case, it's a dead end. Again, IMHO it's fine to done nothing. Moreover, I would like to insist that in last years, I don't think that such case occurred frequently. To be honest, I fail to find any example... Advantages. We saw drawbacks. What are advantages of a democracy where every core developer vote counts? First, the BDFL is no longer a bottleneck. Last years, Guido became less available, some PEPs took a lot of time to be approved, I'm thinking about PEP 525 and PEP 530. Moreover, core developers can take holiday. You are allowed to take care of friends, family, and just have a break. It's fine. There are other people who will take care of Python for you. The decision becomes taken by "the community" (core developers in practice) rather than an individual. Negative comments should no longer target an individual but the collective decision. Being a public person is not easy, it seems like Guido resigns partially because of that pressure. I know that Brett Cannon also suffered of negativity of some haters of the Internet. I also had a depression recently caused partially by Python. Working on an open source and public project causes specific issues. == Annex For Council Lovers == We already have a concept of *councils*. When I have a question on importlib, I will first ask Brett Cannon. If he is not available, I would ask Nick Coghlan and Barry Warsaw. When I have a question on C internals, I will ask Serhiy Storchaka and INADA Naoki. We even have a written list of "experts" (or "maintainers"): https://devguide.python.org/experts/ Note: this list is filled by core developers who add themselves :-) These experts are known references in their domain, and it's common that Guido delegates his BDFL role on PEPs. For example, INADA Naoki is the delegate of two Unicode PEPs: Nick's PEP 538 "C locale coercion" and my PEP 540 "UTF-8 Mode". If Naoki would reject my PEP, I would be fine with that: I trust and respect his judgment. == Summary == It is already very hard to become a core developer: a contributor only becomes a core dev once other core developers trust them. I propose to trust core developers judgment and let them all decide if a PEP should be accepted (or rejected). Common PEPs would require "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python language) would require 66%+1 majority (2/3). Known experts will help to lead the discussion and to refine the PEP. Core developers will decide when they consider that a PEP is mature enough for a vote. If a PEP is rejected by a vote, the author is free to make a new attempt 6 to 12 months later with a new PEP, maybe with a new stronger rationale and better examples. Or a competitor PEP can be proposed by a different author. I expect that the common case will be that the author will not attempt a new similar PEP since the vote result will be explicit enough. Rejecting a PEP doesn't mean a failure for Python: sometimes, doing nothing is the wisest choice :-) Victor

12 28

Proposal: an explicit, time-limited moratorium on finalizing any governance decisions
by Nathaniel Smith 20 Jul '18

20 Jul '18

[tl;dr: We need some ground rules, because uncertainty makes it hard to think straight. But if we get sucked into a complicated meta-debate about the ground rules then that defeats the purpose. My proposal for a Minimum Viable Ground Rule: let's all agree not to finalize any governance decisions before October 1.] We're in a constitutional crisis, and that's scary. There's no map and none of us know what to expect. It feels like anything could happen. You look at the mailing list and see people making big proposals -- is one of them going to suddenly be adopted? If I look away for a few days, will I come back and find out that something's been decided? What are we even talking about? Do I need to jump into that thread RIGHT NOW? It's scary. People don't do their best work when scared. When we're scared it's harder to listen and build up common ground with others -- but that's exactly what we'll need to do to get through this. And also, like... being scared sucks. I would prefer to be less scared. So: can we do anything to make this less scary? One thing that would help is if we had some ground-rules for how the decision itself will be made. Knowing what to expect makes things less scary. There's another thread going on right now trying to do that (subject "Proposal on how to vote"). But... if you look at that thread, it turns out deciding on how to vote is itself an important decision with lots of subtle issues, where we probably want to give people time to think, brainstorm, critique. Heck, in the end we might decide a vote isn't even the best approach. So I'm not saying we shouldn't be having that discussion, we definitely should, but... it's also giving me a new source of anxiety: that we'll all be so eager to get *some* certainty here that we'll end up trying to force a decision prematurely. Kind of a catch-22: the decision about how to make complex decisions is itself a complex decision, which is what we don't know how to do yet. Is there some way to avoid this loop? Can we come up with some ground rules simple enough that we can agree on them without a big debate? Well, there's one thing I am pretty sure of: this is a big decision, there's a lot to think about and talk about, and that we won't regret taking some time some time to do that. And besides, trying to force it to happen faster will make people more scared and dig in their heels. So here's my proposal for an initial, Minimum Viable Ground Rule: we should set a date and promise that no actual decisions will be finalized before that. Until then we are just talking and brainstorming and gradually converging on points of consensus. (And to be clear, the point of this is to give us breathing room, not set a deadline -- we shouldn't dawdle, but if we get there and it turns out we need more time, then that's OK.) What would be a good date? The core sprint is coming up Sept. 10-14, and this seems to be a likely topic of conversation there. And then after the sprint, those who aren't present will need time to catch up with any discussions that happened at the sprint. So to make things concrete, I propose: no governance decisions finalized before October 1, 2018. Probably this is what will end up happening anyway, but if we make it explicit in advance and tell everyone, then at least we'll all know that it's OK to stop refreshing our email constantly and redirect that energy in more useful directions. What do you all think? -n -- Nathaniel J. Smith -- https://vorpus.org

18 38

An alternative governance model
by Barry Warsaw 20 Jul '18

20 Jul '18

I’d like to propose an alternative model, and with it a succession plan, that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it proposes to not actually change that much! TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you’ll have to read on for the big reveal. Why keep a singular BDFL? I think it’s clear that no one can completely replace Guido, and neither should we try, nor do we need to. The discussion to date has explored refactoring many of the roles that the BDFL has, and that’s all excellent, especially to reduce the burden and burnout factor of the NBDFL. But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term. A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative than “Alice Jones, BDFL”. This also comes into play for shutting down discussions early. With a committee, it’s possible that you’ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python’s evolution. Alice Jones may say “No, that’s not gonna happen” only to be overruled or undermined by Bob Smith’s “That’s a good idea”. Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention. I also think a council will be much more risk adverse than a singular BDFL, and that’s not necessarily a good thing. While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering. I hope Guido won’t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding. The question for any new leader is: What is your vision for Python? This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades. Yes, Python is a mature language, but it’s far from stagnant. Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn’t or couldn’t always clearly articulate them. The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that’s okay! A strong vision is better than no vision. Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment. As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo? Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance position, to actually move the language and its primary implementation forward? I’m not so sure. For these reasons I propose that we retain a singular BDFL. The formation of a formal Council is still a good idea! I just think that it shouldn’t be the ultimate arbiter of decisions for Python. So what would the Council do? - It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power. - The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL. - The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions. We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It’s just that the roles and responsibilities would differ. The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors. I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later. If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)… Brett Cannon I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader. He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He’ll be able to delegate where appropriate, and make definitive pronouncements where needed. Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down. He may have specific requirements for accepting the position, but I’ll let him articulate those. I’m confident they would come across as completely reasonable. :) To summarize: * We retain a singular BDFL to lead Python * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL. That’s it in a nutshell. Thanks for listening. Cheers, -Barry

25 73

[RELEASED] Python 3.4.9rc1 and Python 3.5.6rc1 are now available
by Larry Hastings 19 Jul '18

19 Jul '18

On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.9rc1 and Python 3.5.6rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.9rc1 here: https://www.python.org/downloads/release/python-349rc1/ And you can find Python 3.5.6rc1 here: https://www.python.org/downloads/release/python-356rc1/ Python's entrenched bureaucracy soldiers on, //arry/

1 0

Language moratorium
by Stefan Krah 19 Jul '18

19 Jul '18

Hi, if I remember correctly, we had a moratorium for language changes around versions 3.2-3.3. I think during that time relatively few BDFL-level decisions were required. Perhaps we could have one again, say for 12 months so we can figure things out. Other Python implementations may welcome the moratorium so they can catch up. During that time we could just informally listen very closely to Guido if anything requires a decision and he happens to be around. But there may be no decisions at all. And yes, I guess we can successfully attempt to be nice, especially to him (thanks for this wonderful language!). Stefan Krah

9 14

python-committers July 2018