Re: [python-committers] Transfer of power
> > > How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, > The root "vir" in appropriate contexts (though clearly not in all, e.g in `virile`) has long been divorced from its original "male" denotation. The best example is probably in the word "virtus" (in English, "virtue") and further derivatives (e.g "virtuoso", an Italian word which has also been adopted in English), where nobody perceives a denotation of "maleness" any more (even though a long time ago the word was coined to refer to "a male's positive traits" such as courage and strength). I contend that "triumvir" today has no more denotation of maleness than "virtue" does -- e.g, Merriam-Webster defines it as "one of a commission or ruling body of three" (appropriately gender-neutral) and I think they're spot-on about this. Alex ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] An alternative governance model
Barry, you offer truly compelling arguments for a new BDFL as GvR's successor -- FWIW, you've convinced me. And Brett would be an absolutely outstanding pick as that "new BDFL" -- on this, I need no convincing. Alex On Tue, Jul 17, 2018 at 7:08 PM Barry Warsaw wrote: > 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 t
Re: [python-committers] An alternative governance model
Since 1179 (and with a few very minor exceptions in the centuries right after then -- none since 1612), the Catholic Church requires a super-majority of 2/3 to elect a new Pope. I don't see how the choice of a BDFL is so much more important to the Python community, than the choice of a Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 seems unwarranted. In fact, a 90% requirement gets dangerously close to a requirement for unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and thus end the session and nullify every decision made in the session. As https://en.wikipedia.org/wiki/Liberum_veto puts it, "Many historians hold that the liberum veto was a major cause of the deterioration of the Commonwealth political system" all the way to the partitions of Poland. Let's steer well clear of this: those who cannot remember the past, etc, etc... Alex On Wed, Jul 18, 2018 at 11:07 AM Łukasz Langa wrote: > > > On Jul 18, 2018, at 11:54 AM, Ethan Furman wrote: > > > > Are you saying that we should use some method besides voting, or that a > higher percentage of yea votes is required? If the latter, I have no > problem with 66% or 75%. > > The cleanest way would be for Guido to choose but he already said he wants > to stay out of the process. > > With that in mind, one alternative is for the President of the PSF to > choose ;-) > > ...so realistically the only alternative is a vote. Given the gravity of > the situation (a decision on how future decisions are made; long-term > consequences), I propose: > > 1. Define a committer as anybody with GitHub privileges. While not > everybody on this mailing list decided to get GitHub credentials, they can > do it at any point. At the same time, by defining the committer set as > GitHub contributors, we solve the issue of inactive contributors. And this > is important because... > > 2. Require 90% participation for the vote to be valid. > > 3. Require 90% votes in favor for the proposal to pass. > > If 2. or 3. fail, back to the drawing board. I'd lower those requirements > only after a few consecutive votes fail. > > - Ł > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
There are plenty of precedents for mandatory voting, but the enforcement
mechanisms (if any) appear not to be applicable to our case. Note the "if
any": several countries declare voting a citizen's duty (in their
Constitution or otherwise) but don't actually enforce this duty in any way.
For example, that's the case in the United States: if you apply for
naturalization you will be quizzed on many things, including "what are the
duties of a citizen", and one of the latter is "participate in the
democratic process" which includes voting -- but if you don't, no
enforcement action is taken against you. In contrast, if you get a jury
summons (jury duty being another of those citizen duties) and repeatedly
fail to show up, you may end up in jail -- now THAT is enforcement of the
duty (and no Python community organism has, nor should have, such power of
enforcement.
In Italy, where voting is declared to be a duty in the Constitution, at the
start of the Republic you'd get (until next election) a stamp of "non ha
votato" ("did not vote") in your publicly accessible judiciary record (it
would come up in any background search -- and, in a country where firing
employees was notoriously hard, some opined that such a flaw might be
grounds for dismissal if the employer so wished, although I've never heard
of it happening). That was abolished 25 years ago, in part because it was
randomly/capriciously enforced (many judicial districts were too
otherwise-busy to go through voting records and apply/remove the stamp!-).
So, now, Italy is in the vast camp of countries declaring voting a duty
(Italy's constitution was not changed on this subject) but not enforcing
the "duty" at all (indeed, failing to show up to vote is now often
advocated by adversaries of referendums, which have a 50% minimum
participation threshold to be valid and may well be easier to defeat by
getting people to just not show up -- since many others won't anyway for
other reasons -- than by getting them to vote against).
Since I originally brought up a parallel between "which BDFL" voting, and a
Papal conclave, I would be remiss to fail to mention that since 1274 the
Cardinals are locked up "with a key" ("cum clave") until a Pope does get
elected -- usually a good-enough incentive to vote (though once the
citizens of the town where the conclave was held had to decide after a few
failed votes to only send in bread and water -- and later, said citizens
removed the roof of the palace where the Cardinals were locked up, hoping
that rain may speed up the proceedings). Colorful, but, again, not really
applicable in our case.
What's left? The "public naming and shaming" Italy used until a quarter
century ago might work -- just make a little site listing the committers
who, while having a right to vote, haven't voted (yet). A VERY long voting
period might also help -- amendments to the US Constitution originally had
unlimited times for ratification (the 27th amendment, originally the 2nd
one proposed in 1789, was ratified 202 years after proposal), though these
days 7 years is a more customary time limit for ratification. Not sure if
these are good ideas.
Another possibility is to avoid having separate thresholds for
participation and approval (US constitution amendments work that way --
with the specifics being a threshold only for approval out of all States,
not how many States have voted for or against). I.e, if we decide 2/3 is
OK, a proposal might be approved if 2/3 of *eligible* voters have voted for
it -- no matter how many of the remaining 1/3 have voted against, or not
(yet?) voted at all (since, if 100% of eligible voters could be bothered to
vote, once the proposal gets 2/3 of the votes in favor, it does not matter
whether the remaining 1/3 vote against, abstain, or whatever). This is not
mutually exclusive with other ideas (of which, out of what I've mentioned,
the viable ones -- though not necessarily wise! -- would be "public naming"
of non-voters, and VERY long voting periods).
Lastly, I suspect two votes should be separated: (1) what model we adopt
(BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO
is going to serve (as BDFL, as triumvirate member, and so on)...
Alex
On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft wrote:
>
>
> > On Jul 18, 2018, at 6:18 PM, Łukasz Langa wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon wrote:
> >>
> >> While I am totally fine with a super-majority of votes for something to
> be accepted, I don't think the minimum participation requirement will work.
> If people simply choose not to vote then they choose not to (we have no way
> to really compel people to vote).
> >
> > It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it
> happening often. There are countries where voting is mandatory.
>
> Given that we don’t have a lot of levers in our tool chest to compel
> voting, what would you pr
Re: [python-committers] An alternative governance model
On Wed, Jul 18, 2018 at 4:09 PM Fred Drake wrote: > > On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya > wrote: > > Let's be clear that we're not yet at the stage where we can vote for > anything, let alone how to vote. > > On Wed, Jul 18, 2018 at 6:03 PM Łukasz Langa wrote: > > I don't understand what you mean. Before we get to vote on a variant of > PEP 2, we need to decide how we are supposed to perform that vote. This > needs to be decided before we discuss councils, dictators, and so on > because it's all moot if there is no accepted way to agree which governance > model we want. > > Humans do so love to argue! > No we don't! (cfr http://www.montypython.net/scripts/argument.php)... Alex ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal on how to vote (was: An alternative governance model)
Hi Brett, On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon wrote: > [can I just say how much I've missed having both you and Tim around, Alex? > 😃] Heh, good to hear!-) Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) > Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84 (at least not in the US with our `Imperial` system; does it work any differently in Canada with Metric?-)... Alex ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions
FWIW, +1. Alex On Wed, Jul 18, 2018 at 7:36 PM Nathaniel Smith wrote: > [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 > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Vote on governance will happen between Nov 16 - Nov 30
While I suspect most participants are aware of this, just in care some don't I thought I'd just point out that it's futile to look for a "perfect" voting system -- Kenneth Arrow proved that long ago, see https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem Alex On Tue, Oct 23, 2018 at 9:08 AM Tim Peters wrote: > > [Donald Stufft ] > >> ... >> I’m struggling to find a resource besides that doesn’t also include >> shilling for another voting system or isn’t a lengthy paper but >> https://rangevoting.org/IRVpartic.html gives an example and >> https://rangevoting.org/TarrIrv.html is a more complex example. >> > > The rangevoting site has a great deal of info about all sorts of voting > systems. Over a decade ago, Ka-Ping Yee (who used to be very active in > Python development) ran some _visual_ voting simulations on 5 popular > systems, which scared him (& me) away from IRV forever: > > http://zesty.ca/voting/sim/ > > """ > The following images visually demonstrate how Plurality penalizes centrist > candidates and Borda favours them; how Approval and Condorcet yield nearly > identical results; and how the Hare method yields extremely strange > behaviour. Alarmingly, the Hare method (also known as "IRV") is gaining > momentum as the most popular type of election-method reform in the United > States (in Berkeley, Oakland, and just last November in San Francisco, for > example). > """ > > That said, in the absence of political factions maneuvering to increase > their own power over time, with money and marketing clout to persuade > voters to play along, I'm not much concerned about the system used for a > one-shot vote. Even if we all strive to be as "strategic" and/or > "tactical" as possible, we'll all be pushing in different directions. > > One massive (to my eyes) advantage of range voting is that it never pays > to give your true favorite less than your top score, or your true > least-favorite more than your bottom score. (Note: the "approval voting" > used for PSF elections is essentially range voting limited to two possible > scores - and it should be very easy in that context to see that it can't > pay to approve a candidate you don't approve of, or vice versa.) > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Please add your GitHub username to your bugs.python.org account
I still see a 404 at https://github.com/orgs/python/teams/python-core . Alex On Mon, May 2, 2016 at 10:45 AM, Brett Cannon wrote: > OK, all done! For those of you already members of the Python org on GitHub > you should be added already. For those of you who weren't, check your email > for an invite (except for Alexander and Paul; you two are getting personal > emails about issues). > > I have also made Antoine and Georg team maintainers as they are currently > for hgaccounts. > > And FYI, there are 68 of us assuming everyone accepts their invites. > > > On Mon, 2 May 2016 at 10:27 Brett Cannon wrote: > >> I have created https://github.com/orgs/python/teams/python-core and I am >> now beginning to add names. From this point forward you will need to >> manually tell me or [email protected] your GitHub username if it >> isn't already on bugs.python.org. >> >> I'll email here again when I'm done so people can check that they were >> added to the team properly. >> >> On Sun, 1 May 2016 at 14:14 Brett Cannon wrote: >> >>> I realized I was ambiguous in my phrasing; yesterday I was given >>> tomorrow off, so I will start adding names on May 2nd at some point (and >>> I'll email here when I start). >>> >>> On Sun, May 1, 2016, 10:09 Brett Cannon wrote: >>> Last reminder on this: I got the day off work yesterday and so I'm going to spend it creating a "Python core" team on GitHub and adding all of the usernames you have all put into bugs.python.org (and don't worry, I plan to go for a nice walk after I'm finished to actually enjoy my day off) . I'll reply to this thread one last time when I begin creating the team as after that point you will need to personally let me know and/or hgaccounts what your GitHub username is to be added to the team (I will also update the devguide as part of creating the team about this). On Fri, 22 Apr 2016 at 16:13 Brett Cannon wrote: > Just a quick reminder for folks to please fill in their GitHub > username on bugs.python.org by May 1 if possible to make my and your > life easier. > > We are on track to move our first repository to GitHub before PyCon US > (devinabox to start, hopefully another one like peps and/or the devguide > as > well shortly thereafter if there's time), so it will soon not be a > hypothetical thing to want to have GitHub access. > > On Mon, 4 Apr 2016 at 16:45 Brett Cannon wrote: > >> If you go to your bugs.python.org account you will notice there is >> now a "GitHub Name" field. Please fill that in with your GitHub username >> sometime this month. You can see who has already filled in their username >> by going to >> http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300 >> . >> >> Let's aim to have those fields filled in by the end of the month? >> It's not a huge deal if you don't get to it in time but it makes my life >> easier if I can add everyone to the python-dev -- or maybe >> python-committers; haven't chosen the name yet -- team on GitHub at once >> instead of piecemeal over time. I'm hoping to get devinabox, benchmarks, >> peps, and devguide repositories moved to GitHub by PyCon US, hence why >> I'm >> asking people do this now instead of later. >> > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Please add your GitHub username to your bugs.python.org account
My GitHub Name, aleaxit, is at http://bugs.python.org/user16700 and has been ever since April 4. Not sure why you think it isn't? Alex On Mon, May 2, 2016 at 10:51 AM, Brett Cannon wrote: > > > On Mon, 2 May 2016 at 10:48 Alex Martelli wrote: > >> I still see a 404 at https://github.com/orgs/python/teams/python-core . >> > > Apparently team membership is available only to other team members, so if > you have not been added to the team -- as is your case, Alex, as you didn't > put a GitHub username on bugs.python.org -- or you have not accepted the > invite the link won't work for you. > > -Brett > > >> >> Alex >> On Mon, May 2, 2016 at 10:45 AM, Brett Cannon wrote: >> >>> OK, all done! For those of you already members of the Python org on >>> GitHub you should be added already. For those of you who weren't, check >>> your email for an invite (except for Alexander and Paul; you two are >>> getting personal emails about issues). >>> >>> I have also made Antoine and Georg team maintainers as they are >>> currently for hgaccounts. >>> >>> And FYI, there are 68 of us assuming everyone accepts their invites. >>> >>> >>> On Mon, 2 May 2016 at 10:27 Brett Cannon wrote: >>> I have created https://github.com/orgs/python/teams/python-core and I am now beginning to add names. From this point forward you will need to manually tell me or [email protected] your GitHub username if it isn't already on bugs.python.org. I'll email here again when I'm done so people can check that they were added to the team properly. On Sun, 1 May 2016 at 14:14 Brett Cannon wrote: > I realized I was ambiguous in my phrasing; yesterday I was given > tomorrow off, so I will start adding names on May 2nd at some point (and > I'll email here when I start). > > On Sun, May 1, 2016, 10:09 Brett Cannon wrote: > >> Last reminder on this: I got the day off work yesterday and so I'm >> going to spend it creating a "Python core" team on GitHub and adding all >> of >> the usernames you have all put into bugs.python.org (and don't >> worry, I plan to go for a nice walk after I'm finished to actually enjoy >> my >> day off) . I'll reply to this thread one last time when I begin creating >> the team as after that point you will need to personally let me know >> and/or >> hgaccounts what your GitHub username is to be added to the team (I will >> also update the devguide as part of creating the team about this). >> >> On Fri, 22 Apr 2016 at 16:13 Brett Cannon wrote: >> >>> Just a quick reminder for folks to please fill in their GitHub >>> username on bugs.python.org by May 1 if possible to make my and >>> your life easier. >>> >>> We are on track to move our first repository to GitHub before PyCon >>> US (devinabox to start, hopefully another one like peps and/or the >>> devguide >>> as well shortly thereafter if there's time), so it will soon not be a >>> hypothetical thing to want to have GitHub access. >>> >>> On Mon, 4 Apr 2016 at 16:45 Brett Cannon wrote: >>> If you go to your bugs.python.org account you will notice there is now a "GitHub Name" field. Please fill that in with your GitHub username sometime this month. You can see who has already filled in their username by going to http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300 . Let's aim to have those fields filled in by the end of the month? It's not a huge deal if you don't get to it in time but it makes my life easier if I can add everyone to the python-dev -- or maybe python-committers; haven't chosen the name yet -- team on GitHub at once instead of piecemeal over time. I'm hoping to get devinabox, benchmarks, peps, and devguide repositories moved to GitHub by PyCon US, hence why I'm asking people do this now instead of later. >>> >>> ___ >>> python-committers mailing list >>> [email protected] >>> https://mail.python.org/mailman/listinfo/python-committers >>> Code of Conduct: https://www.python.org/psf/codeofconduct/ >>> >> ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit
On Tue, Jan 24, 2017 at 1:26 PM, Neil Schemenauer wrote: > On 2017-01-24, Victor Stinner wrote: > > You should take a look at this old deferred PEP: > > https://www.python.org/dev/peps/pep-0407/ > > Thanks, that's very close to what I was thinking. I would still add > that we should be extra careful about incompatible language features > until 2.7.x usage has mostly died off. That isn't logically part of > the PEP but a general development philosophy I think we should > adopt. > I love that PEP. However, I don't think the best way to attract large masses of people away from 2.7 and onto 3.* is to avoid adding features to 3.* releases: such an approach would not offer compelling reasons to migrate, as needed to overcome natural inertia. Rather, thinking of what arguments I could bring to add further support to a case for migration (wearing the "consultant's hat" which I haven't donned in 12 years, so, I'm a bit rusty:-) I think: performance/scalability; stability; cool new features; whatever extra gizmos may help existing 2.7 code run fine under new shiny 3.whatever with only automated code transformation steps in the way (reverse migration, i.e 3.foobar -> 2.7, nowhere near as important). A lot of this describes stuff that HAS been happening -- the "stability" point would be particularly well addressed by PEP 407 or some variant thereof... Alex ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
