Python post-Guido [LWN.net]

Python post-Guido

Posted Jul 17, 2018 19:51 UTC (Tue) by Tara_Li (guest, #26706)
Parent article: Python post-Guido

Not a part of the Python community - I've ever only read snippets of code, because I hate a language where exact white space plays such a critical role. But from the outside - they're making a big mistake by moving towards a committee game.

BDFL worked *wonderfully* for the community for a long time, as far as I can see. It's working pretty darned well for the Kernel community as well. I seem to remember Perl used (or maybe still uses) something similar - the Patch Pumpkin.

The point, though, is to keep responsibility concentrated. With a committee, it gets harder and harder to pin down exactly *who* made the mistake - responsibility gets diffused, and eventually nobody owns up to stripping the threads on the screws.

An election for BDFL or Patch Pumking, or whatever makes some sense - though I would suggest requiring a fairly high majority (75-90%) to actually pick one. If it's simply 50%+1, then you have a likely significant disgruntled minority that may cause problems in the future.

to post comments

Python post-Guido

Posted Jul 17, 2018 20:08 UTC (Tue) by ju3Ceemi (subscriber, #102464) [Link] (3 responses)

Indeed

Dictatorship is still the best "ruling" system for a "project", because it allows the few to do what is necessary for the most

It also enforce this guy's commitment, because he is taking a frontal responsability in decisions

Python post-Guido

Posted Jul 17, 2018 21:12 UTC (Tue) by edomaur (subscriber, #14520) [Link] (2 responses)

Well, no.

For example, the Rust language project hasn't had a BDFL since when Graydon Hoare left. And now, it has various teams handling each a set of responsibilities : Core Team is the governance and direction of the project, Language Team is the language features design team, etc. ( https://www.rust-lang.org/en-US/team.html )

It works, the language is not even as "designed by committee" as C++

And yes, there is also a CoC : https://www.rust-lang.org/en-US/conduct.html

Python post-Guido

Posted Jul 18, 2018 14:40 UTC (Wed) by malefic (subscriber, #37306) [Link] (1 responses)

Rust also has a bunch of people working on it full-time, backed by a large corporation with a clear set of goals. It is not a community project in a sense Python is. It is also worth mentioning that, despite all the buzz, Rust is still a niche language compared to Python, and there are probably far fewer people suggesting various "syntax improvements" on the mailing lists.

I think that dictatorship is the only way to keep Python going off the rails. Whether it's a single BDFL or three doesn't really matter.

Python post-Guido

Posted Jul 19, 2018 5:09 UTC (Thu) by edomaur (subscriber, #14520) [Link]

" It is not a community project in a sense Python is."

And how does it even matter ? The decision process is completely open and Rust is not Java even if there are corporation backed contributors. And about the "niche language" aspect, that's true that the Rust community is (at least for the moment) smaller than the Python one, but Rust is quite young too. What I tried to communicate was that it just seems to work and that from the beginning they tried to follow a scalable approach to language design.

Their is not much example of bad "dictatorized" project still around, because they tend to die or to be forked. However, I realize that perhaps I misunderstood what you were meaning with "dictatorship" : are you, by this word, speaking about arbitration authority ? Like, the Debian Technical Committee, the LibreOffice Engineering Steering Committee, how the various project in Apache are managed and so on ? Having a unique Man having the role of a local god is not the most successful way of doing community but yes, there are some real high profile exceptions. And even then, in the case of Linux it's not a dictatorship anyway, it's more a "release managership" (imho)

Python post-Guido

Posted Jul 18, 2018 14:44 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

BDFL worked *wonderfully* for the community for a long time, as far as I can see. It's working pretty darned well for the Kernel community as well. I seem to remember Perl used (or maybe still uses) something similar - the Patch Pumpkin.

Projects that start life with BDFL-style leadership can do really well with it because their leader has a chance to establish their reputation for competence while the project is small and the cost of failure is low. They also have the opportunity to learn management incrementally as the project grows around them. Finding a replacement BDFL is going to be really hard because they'll have all the management responsibilities the old BDFL without the experience and goodwill the founder had by the time they left.

I think that's why projects tend to move away from the BDFL model when the founder leaves. Having a committee instead of a single leader provides some redundancy and protection against making a bad choice in their replacement. Even projects that have a single leader rather than a committee tend to give their new leader a limited term, which at least limits the potential damage from making an unfortunate choice.

Python post-Guido

Posted Jul 19, 2018 13:28 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

My first thought was whether the Python 3 language should be declared finished? (Additions to the "batteries included" libraries still allowed, provided they do not ever break the older components).

Work could then start on Python 4, under a new management.

I don't know enough to recommend this, but an idea would be to call it "Mamba" instead of "Python 4" , and in the first instance to make its primary purpose the replacement of the Global Interpreter Lock with something that's more amenable to parallelization. Would this be more possible if some small parts of the Python 3 language were removed or redefined, in ways which still allowed the majority of Python 3 code to be re-used?

My second thought was of the Norwegian Blue parrot. I still don't know precisely why.