LWN: Comments on "Python post-Guido"

Python post-Guido

spaetz — Sat, 28 Jul 2018 09:39:28 +0000

Because he is only taking an indefinite vacation 😃. There is no way to return that title.

Python post-Guido

mcortese — Sat, 28 Jul 2018 06:04:33 +0000

Why are we still refering to Guido as the BD for life? Shouldn't it be changed into BD for some time?

silly word games

nix — Thu, 26 Jul 2018 15:58:50 +0000

You don't want to keep the 'wo-': its root was 'wif', thus defining a woman with reference to the man who was her husband. (English is weird, one of very few Indo-European languages whose word for 'woman' does not derive from PIE *gʷḗn, though obviously that is still around as a term for one woman in particular. Or, at least, one woman at a time. Note: the female name 'Gwen' is probably unrelated.)

silly word games

gus3 — Tue, 24 Jul 2018 03:26:42 +0000

"Per-offspring," not "per-son."

Python post-Guido

gerdesj — Sat, 21 Jul 2018 22:00:45 +0000

"from a noun whose grammatical gender is masculine."

English (language) strips gender from nouns. La table is the table, das wasser is the water, we only have one definite article in English. Tyrant does not proscribe a gender in English in the same way that the direct translation for vir is man (cf virile etc). Greeks might have assumed that a tyrant was male but the word does not mean "man that is a tyrant".

Anyway, I was taking the piss. lol 8) etc

The name "Python"

flussence — Fri, 20 Jul 2018 18:39:48 +0000

Nice one-liner! You forgot the "$" though.

silly word games

edgewood — Fri, 20 Jul 2018 17:14:00 +0000

wo-per-daughter, please

silly word games

sdalley — Fri, 20 Jul 2018 15:12:00 +0000

Aaand, while we're at it, let's change wo-man to wo-person....

Python post-Guido

sb — Fri, 20 Jul 2018 13:04:38 +0000

And by the same logic your proposal would also be sexist, because it derives from a noun whose grammatical gender is masculine.

But why?

edgewood — Fri, 20 Jul 2018 11:55:27 +0000

My sense of why not take twelve months (from the reporting and light skimming of some of the threads on the mailing list) is that they might have been happy to have a twelve month discussion that made progress the whole time. The actual discussion had a lot of addressing the same points over and over and over again. I can understand why they didn't want to continue doing that.

But why?

NAR — Fri, 20 Jul 2018 09:30:43 +0000

"What would be the negative consequences of PEP 572 taking twelve months, or five years to search for consensus ? Other than those in favour didn't want to wait?"

It raises the possibility of "filibuster" and the language getting stuck/obsolete.

Python post-Guido

gerdesj — Thu, 19 Jul 2018 23:19:52 +0000

"n-virate" is going to need someone to come up with a non sexist version of that term. The original or at least most famous triumvirate - JC and Co - was at least accurately descriptive: there were three men. Vir means man in Latin, so perhaps something involving populi might work instead.

You could call it a committee but that word is only a few hundred years old so may not be cool enough. What about spicing it up as say Python Tyrant Committee or Pythonic Committee of Tyrants? Here I mean tyrant in its original meaning (soon to be seriously blemished by err tyrants being tyrants.) See https://en.wikipedia.org/wiki/Tyrant first para ("The original Greek term ...")

But why?

tialaramex — Thu, 19 Jul 2018 14:42:37 +0000

[Meant to post this some time ago but forgot LWN has a "confirm" step instead of editing comments]

But do you think ramming through PEP 498 worked out better because this is generally a good way to do things and PEP 572 was just bad luck?

I'm looking back at things like PEP 414 (unicode literals in Python 3 so that more Python 2 code "just works") and I see plenty of effort put into figuring out what's actually objectionable here, let's narrow this down and do just the minimum possible to make the most people happy while annoying as few as possible.

My feeling is that with PEP 498 there was an attempt to shortcut, "I can't be bothered to persuade these people that I'm right, so we'll just do it, and then hopefully they'll come along".

But that's doubly risky, the least awful outcome is that you were right but you alienate loads of people and cause unnecessary strife, which seems to be what Guido thinks happened here. And actually it's also possible that since you insisted on doing it anyway you were wrong, you will eventually _realise_ you were wrong and so either it's going to get reversed out or the language will fade away ("Remember when Python didn't have that stupid assignment bug?").

Again, I bring this up because we're talking about programming languages here. This is not a penalty shoot-out, we have great luxury of time. What would be the negative consequences of PEP 572 taking twelve months, or five years to search for consensus ? Other than those in favour didn't want to wait?

Python post-Guido

NRArnot — Thu, 19 Jul 2018 13:28:21 +0000

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.

Python post-Guido

edomaur — Thu, 19 Jul 2018 05:09:57 +0000

" 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)

The name "Python"

antiphase — Wed, 18 Jul 2018 17:38:36 +0000

> I wouldn't worry about the "capture" scenario at all.

Nice try, Microsoft.

Late breaking development

jake — Wed, 18 Jul 2018 16:31:01 +0000

Barry Warsaw has presented an alternative idea for Python governance in a lengthy post to the committers list:

https://www.mail-archive.com/python-committers@python.org...

He proposes continuing with the idea of a BDFL backed by a council that would provide some assistance to the BDFL as well as some checks and balances on their power should things go awry. He suggests that Brett Cannon fill that role:

> 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.

So far, the reaction has been quite positive. We will be keeping an eye on things and write more about this transition in the future. Stay tuned ...

jake

But why?

malefic — Wed, 18 Jul 2018 15:02:25 +0000

> the problem of "Let's make this change lots of people oppose" isn't fixed by having a triumvirate

PEP 572 is an outlier. Most PEPs are accepted or rejected without so much fuss, even when there's some opposition. PEP 498 (Literal String Interpolation) in Python 3.6 was also vigorously opposed ("why do we ever need a *fourth* formatting method??!"), but is now accepted as one of the best features of Python 3. The BDFL is there to make the final decision, however unpopular at the time of inclusion, and to provide overall design consistency through their vision and taste. This is much better than making decisions through a coin toss.

The name "Python"

malefic — Wed, 18 Jul 2018 14:46:56 +0000

> It's an interesting point that a triumvirate is vulnerable to capture by an organization

GvR has been consistently employed by various organizations throughout his tenure as BDFL, including Google.

Ultimately, the person or persons chosen as his replacement would be people with a great deal of respect and trust. I wouldn't worry about the "capture" scenario at all.

Python post-Guido

rgmoore — Wed, 18 Jul 2018 14:44:48 +0000

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

malefic — Wed, 18 Jul 2018 14:40:30 +0000

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.

But why?

tialaramex — Wed, 18 Jul 2018 09:38:52 +0000

Ugh, s/apantomany/apantomancy/ - Diviniation through chance encounters.

But why?

tialaramex — Wed, 18 Jul 2018 09:37:45 +0000

It remains unclear to me why language developers are so sure that they _need_ a mechanism by which controversial changes to a successful languages get made. I very much doubt that it matters which hopelessly inappropriate mechanism you choose, the problem of "Let's make this change lots of people oppose" isn't fixed by having a triumvirate, or choosing by coin tosses, or apantomany ("if the next bird I see is a swan, we're applying the patch").

Python post-Guido

marcH — Wed, 18 Jul 2018 03:52:40 +0000

> What is the cost of posting to a [PEP] discussion thread vs the cost of everyone reading that post?

Basically the definition of the Internet. Let us know when the Python community has a fix.

Python post-Guido

gus3 — Wed, 18 Jul 2018 02:40:35 +0000

I see this as Guido doing an experiment on a stable project: crowd-sourcing a new management scheme. Of course, I could be wildly wrong; I don't have any particular insight into Guido's mind. I don't even use Python on any regular basis, but my ex-wife certainly does. (No, that isn't why she's my ex. I promise.)

I just bought a "starving hacker" subscription to LWN.net, in order to read this article & see how the immediate aftermath is playing out. I'll admit, I like what I see.

Oh, and you're welcome. It's the least I could do, to repay Mr. Corbet. After all, he helped me write a working kernel device driver.

Python post-Guido

edomaur — Tue, 17 Jul 2018 21:12:00 +0000

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

The name "Python"

epa — Tue, 17 Jul 2018 20:11:59 +0000

It's an interesting point that a triumvirate is vulnerable to capture by an organization that employs two of the three developers. It sounds a bit paranoid to me (I don't believe commercial software companies are that evil, not even Oracle) but I can see why you have to design for the worst case.

The obvious answer is that if Python did get captured by some company, you could just fork it. Programmers and Linux distributions would soon switch to the fork if it were better managed. But then, could it still be called "Python"? Would you be risking a trademark suit by doing so?

Perhaps at the same time as Guido stepping down as BDFL, the Python Software Foundation should also step down from its control of the "Python" trademark. Their trademark usage policy talks about "the Python programming language" but this is vague and perhaps even circular. In my opinion it would be healthier to explicitly allow a broad range of uses even when the language specification has diverged (so projects like Tauthon wouldn't need to hide under different names).

Then you could be sure that even if the current Python organization gets into governance problems, Python the language and community will be able to continue.

Python post-Guido

ju3Ceemi — Tue, 17 Jul 2018 20:08:19 +0000

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

Tara_Li — Tue, 17 Jul 2018 19:51:59 +0000

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.