Hacker News new | past | comments | ask | show | jobs | submit login
“I'm basically giving myself a permanent vacation from being BDFL” (python.org)
2024 points by randlet on July 12, 2018 | hide | past | favorite | 721 comments

As a personnal note, you could feel that guido was already in this mood for a while from the tone of the last year tickets and mails.

It's amazing he managed to not explode at somebody. I know i would have if our roles had been reversed in some exchanges we had.

Good writers, comedians or directors know when to quit at the top their carreer.

I think he is quitting before the situation was too taxing and that is wise and courageous. Espacially since it's been more than 2 decades of service.

Plus he is leaving his baby.

That's an amazing move.

>It's amazing he managed to not explode at somebody.

Like a certain other BDFL occasionally does?

Maybe this is the reason that the certain other BDFL is still in service? Maybe it's part of psycho-hygiene in order to be able to continue? I sincerely don't know - your question just triggered my experience when working in psychiatry and seeing how the staff was venting, talking and joking about patients - once the doors were closed. I was very shocked, was quite young, around 20 when serving - but one of the doctors, when she saw my shock, took me apart and explained that this behaviour, so shocking it might be when seeing it for the first time, is part of psycho-hygiene that allows the people to be able to continue to work and keep a certain distance.

Sure, it's not the same, but I am questioning myself, if for these roles, like the BDFLs we are talking about, it is not necessary to have a personal way that allows to handle all the pressure, still keeping being yourself, defending your vision of your life-work.

I work in patient safety in English MH settings. The culture you describe is toxic, and I would have reported all of those HCPs to their trust (using the trust complaints process), to the CQC, and possibly to their professional registration bodies.

> is part of psycho-hygiene that allows the people to be able to continue to work and keep a certain distance.

It's also a culture of de-humanisation that allows abuse to continue unchecked. You find this culture in every patient safety scandal: winterborne view, mid-staffs, morcambe bay, cornwall, etc etc.

> The culture you describe is toxic

How? Which parts exactly?

> It's also a culture of de-humanisation

Again, how?

I find it creepy that without any specific examples provided you would report them.

Surely that creates a toxic culture.

The context is someone hearing comments that were "shocking", and that were so shocking they could only be delivered behind closed doors. This is a good, but not infallible, sign of a dysfunctional culture in health care. It might be fine in other industries, but in health care there are strong links between this culture and poor, harmful, practice.

It's interesting that making a complaint is seen as a negative thing to do: if there's no basis for the complaint no action is taken. Action is only taken - the compaint is only negative for the HCP - if the HCP has done something wrong.

> and seeing how the staff was venting, talking and joking about patients - once the doors were closed. I was very shocked,

The standard you walk past is the standard you accept.

Have a read of the reports I mentioned to see where this toxic culture leads.

Here's mid Staffs, but they all say the same: Mid Staffordshire: https://www.gov.uk/government/publications/report-of-the-mid...

> During the course of both the first inquiry and the present there has been a constant refrain from those charged with managing, leading, overseeing or regulating the Trust’s provision of services that no cause for concern was drawn to their attention, or that no one spoke up about concerns

People need to speak up. And when they do speak up, they need to be listened to.

> Negative culture

> While it is clear that, in spite of the warning signs, the wider system did not react to the constant flow of information signalling cause for concern, those with the most clear and close responsibility for ensuring that a safe and good standard care was provided to patients in Stafford, namely the Board and other leaders within the Trust, failed to appreciate the enormity of what was happening, reacted too slowly, if at all, to some matters of concern of which they were aware, and downplayed the significance of others. In the first report, this was attributed in a large part to an engrained culture of tolerance of poor standards, a focus on finance and targets, denial of concerns, and an isolation from practice elsewhere. Nothing I have heard in this Inquiry suggests that this analysis was wrong. Indeed the evidence has only reinforced it.

The first point in the executive summary to the Winterbourne View report says this:

> The abuse revealed at Winterbourne View hospital was criminal. Staff whose job was to care for and help people instead routinely mistreated and abused them. Its management allowed a culture of abuse to flourish. Warning signs were not picked up or acted on by health or local authorities, and concerns raised by a whistleblower went unheeded. The fact that it took a television documentary to raise the alarm was itself a mark of failings in the system.

Staff didn't go to Winterbourne View and immediately start punching people in the face. The abuse started with a culture of dehumanising these people, and closing off the wards to prevent criticism.

> The Serious Case Review also sets out very clearly that for a substantial portion of the time in which Winterbourne View operated, families and other visitors were not allowed access to the wards or individual patients’ bedrooms. This meant there was very little opportunity for outsiders to observe daily living in the hospital and enabled a closed and punitive culture to develop on the top floor of the hospital. Patients had limited access to advocacy and complaints were not dealt with.

Thanks for taking the time to write all this. You are courageous, people often look elsewere when there are abuses.

> The context is someone hearing comments that were "shocking"

Shocking because they were dehumanising or shocking because they were unexpected?

> and that were so shocking they could only be delivered behind closed doors.

My take is that it simply meant out of earshot of patients - and that's basic professionalism - not a sign of dehumanising patients.

They clearly weren't trying to hide their conversations from new staff.

> It's interesting that making a complaint is seen as a negative thing to do: if there's no basis for the complaint no action is taken.

I'd be extremely surprised if that's the case.

Even in the tech world complaints are treated seriously enough that people's lives are negatively impacted regardless of whether there is any basis.

> Have a read of the reports I mentioned to see where this toxic culture leads.

I've read your excerpts and can see no relation to the situation we are discussing.

Once again how does venting or making jokes about patients lead to a lower standard of care?

> The standard you walk past is the standard you accept.

And the parent poster made absolutely no comment about poor standards of care. In fact the implication was clearly that there was a high standard.

> Once again how does venting or making jokes about patients lead to a lower standard of care?

Culture is so important that the Mid Staffs report include an entire chapter about it. You've said that venting is a way for staff to cope with a difficult job. That has already been called out as harmful: https://assets.publishing.service.gov.uk/government/uploads/...

> Aspects of a negative culture have emerged at all levels of the NHS system. These include: a lack of consideration of risks to patients, defensiveness, looking inwards not outwards, secrecy, misplaced assumptions of trust, acceptance of poor standards and, above all, a failure to put the patient first in everything done. The emergence of such attitudes in otherwise caring and conscientious people may be a mechanism to cope with immense difficulties and challenges thrown up by their working lives.

They go on to say:

> A caring culture

> In addition to safety, healthcare needs to have a culture of caring, commitment and compassion. It requires the hard lessons of a Stafford to realise that it cannot be assumed that such a culture is shared by all who provide healthcare services to patients. What are the essential ingredients of such a culture? They surely include:

> Recognition of the need to empathise with patients and other service users;


> A commitment to draw concerns about patient safety and welfare to the attention of those who can address those concerns

I'd suggest that you can't empathise with a patient if you're being unpleasant about them behind closed doors.

My context is health care provided in English MH settings, usually in-patient, usually paid for by the NHS but not necessarily in an NHS hospital or with NHS staff.

> Once again how does venting or making jokes about patients lead to a lower standard of care?

Venting is an HCP placing blame for an event on the patient. This frames future incidents and the responses to those incidents. It makes it more acceptable and more likely for staff to use restrictive practices, and it de-emphasises the skills of de-escalation.

There is wide variation in the use of "prone restraint" in England. Some hospitals do not use it at all. Others use it frequently. Prone restraint can lead to death, so it's important that we understand this variation. One of the differences, but not the only difference, is the culture.

Imagine you're detained against your will in a mental health hospital.

Nurses Ann and Bob have the legal power to get a team of people to force you to the ground, hold you in prone or supine restraint, remove items of clothing to expose your buttocks, and inject a rapid tranquillisation medication. Again, all of this is against your will.

Nurse Ann says, behind closed doors during a team meeting: "Holy crap sheepmullet's anger has been out of control all this week. They wanted Section 17 leave for Christmas[1], but that wasn't granted, and I've got to tell them later and I know they're going to kick off again. They're just so angry at everything I say to them, and I know this is going to send them off the edge."

Nurse Bob says, behind closed doors during a team meeting: "sheepmullet has applied for section 17 leave. This was not granted. I have to tell them later that it has not been granted. I know that sheepmullet was really looking forward to Christmas with their family, and that they will be very disappointed that they're staying in hospital. I've struggled to talk to sheepmullet in a way that helps them contain their anger, and I'd like some advice about how to break this bad news in the best way."

There's not much that is actionable in a complaint from Nurse Ann. The comments aren't shocking. Ann's comments are likely milder than those mentioned in the original comment I responded to. But that approach is more likely to lead to prone or supine restraint, rapid tranquillisation, and a spell of seclusion. These are significant actions and should only be done as a last resort. Prone restraint has the potential to cause death.

Nurse Bob is making use of Soft Words from SafeWards[2], which is used in a range of MH settings, including "Secure Units"[2]. We're pretty sure this approach reduces the need for restraint, rapid tranq, and seclusion.

Imagine you get to chose who looks after you: do you pick Ann or Bob?

> Even in the tech world

Look at airline safety investigation where errors, even errors that kill, are not punished but are sources of learning. This should be true of healthcare, although it isn't always. The solution is not to avoid ever making complaints, but to keep making complaints and force the regulatory bodies to change their complaint handling.

We don't know what the comments were, and obviously if they're innocuous you don't report them. But, and this is really clear from all the investigations and research we have: you need to report disfunctional culture and leaders need to listen and act on those reports.

You seem to be saying that "shocking comments" aren't really shocking, and that non-shocking comments shouldn't be reported. I'd agree that you don't need to report stuff that doesn't need to be reported, but does that need to be said?

> Once again how does venting or making jokes about patients lead to a lower standard of care?

Look at what happened at Winterbourne View. People with intellectual disability were being tortured. There was a collapse in compassion. How did that start? How did we go from a 24 bed ATU providing care to a place where multiple staff felt it was okay to punch patients or trap them underneath chairs or pour mouthwash into their eyes? That started with staff who dehumanised their patients, and that dehumanisation starts with "shocking comments" delivered behind closed doors. A culture of abuse starts with staff thinking it's okay to badmouth patients just because they're behind a closed door. "Canteen culture" - staff sharing unacceptable views behind closed doors - is a widely recognised source of toxicity.

> In fact the implication was clearly that there was a high standard

That's what the midwives at Morecambe Bay said, that this was a good unit providing high quality care with the patient at the centre of everything they do. They were wrong. It was providing such poor care that babies were needlessly dying.

That's what the managers at Mid-Staffs said. We had no way of knowing care was so poor. Everything we had told us it was okay. They were wrong, they had a lot of indicators (including complaints from patients, relatives, and staff) to show that there had been a collapse in compassion in their hospital.

[1] apologies if Christmas means nothing to you. Substitute for something else significant: child's first day at school etc.

[2] http://www.safewards.net/managers/evidence

[3] these units work mostly with people who've been imprisoned or arrested after committing a criminal offence - they work with very ill people who are more likely to be violent. https://www.centreformentalhealth.org.uk/secure-care See also forensic services: http://www.nhsconfed.org/~/media/Confederation/Files/Publica...

Belittling vulnerable people, behind closed doors or otherwise, is not a part of any healthy culture.

I agree. I know some doctors and while they do tell stories about the patients (obviously completely anonymously) and sometimes have a laugh about them, you can always feel certain base level of respect, love and care, not unlike someone telling about their kids doing something silly. Good doctors don't dehumanize their patients, ever.

> one of the doctors, when she saw my shock, took me apart and explained that this behaviour, so shocking it might be when seeing it for the first time, is part of psycho-hygiene that allows the people to be able to continue to work

Did you consider that her taking you apart and explaining it away with that excuse is just as much part of her "psycho-hygiene" that allows her to joke about the suffering and mental well-being of the human beings explicitly left in her care, without feeling bad about it?

I mean, what the hell? I trust my therapists not to laugh about my issues behind my back just like I trust the chef cooks at a restaurant not to spit on my food. Even if in most cases I won't be able to tell, it's a matter of trust and professionalism. I have to trust them on this. I HAVE to be able to honestly believe that a therapist or psychiatrist with a professional attitude and ethics will NOT joke about the most embarrassing issues I trust them with, the moment that I turn my back. Otherwise you can't do therapy with them.

Therefore whatever the hell this doctor thinks they're doing, is very unprofessional.

No matter the excuses they told you. I mean if you need this sort of disrespectful "psycho hygiene" for your mental well-being, first consider if you're even cut out for the job. Maybe look for other parts of the mental health sector, with patients whose problems you find less hilariously funny. Finally, if you really found your calling in one of the rather serious, dark corners of mental health care, the ones that are truly as taxing that merely working there requires counselling lest you burn out, then do exactly that. Vent at a counsellor. You can even joke at them because they're bound to a professional secrecy. Your colleagues aren't. They may be to your patients but not to you and that's the point. It needs to be separate.

And also VERY importantly, that counsellor will tell you when you actually cross the line and venting turns bad. In a social group, between colleagues, and a psychiatrist should know this, there is no such check. There's group pressure. Boundaries are tested. Someone says "maybe that's in bad taste", but next week two other people do it, and the someone doesn't want to keep nagging at colleagues, so the behaviour gets normalised. Boundaries have moved. Now you have a proper toxic environment. And then at some point, a young new 20-something staff-member joins, is shocked about the lack of professionalism. Now they have to be taken apart and explained why this behaviour is considered okay and is normalised. But says who?? There is no oversight, no checks, it's just social pressure and venting between colleagues. Who's there to say "this is enough and this is too much" and how are they qualified to make an objective call about it?

Just out of curiosity, what country's mental health care were you talking about? The quality of that varies widely enough that sure there's enough places in the world where if your story is the worst that is going on, it's probably good and at least it's not neglect or abuse. It's a matter of how high you put the bar. Regardless, a psychiatric doctor shouldn't actively rationalise this behaviour to newcomers.

Quickly getting back to the BDFL topic: There are many ways to handle pressure etc, and the ones that do not require you to occasionally "explode at someone", are in fact healthier and better for one's mental well-being.

> are many ways to handle pressure etc, and the ones that do not require you to occasionally "explode at someone", are in fact healthier and better for one's mental well-being

For instance, taking a vacation. How many times has Guido stepped away from the position and letting whatever "vice" he had make the decisions for a while?

Don’t know why you are being downvoted. Linus’s tirades and diatribes are famous for how brutally personal they get. I still maintain that they are a waste of time and he would be a more effective leader if he limited his responses to “this is a bad idea” or “this isn’t done right” instead of writing pages long personal attacks on other members of the project.

Being 'brutal' is sometimes ok if the brutality is more like 'exposing reality' in nature, and pointed at a situation, not at individuals.

Personal attacks are totally counterproductive, demeaning, and just mean. When they are public, it's especially way out of bounds and I have no respect for someone who does that, it shows a lack of emotional maturity and confidence.

There are definitely idiots in the world, but you don't go around calling them idiots, and certainly not in public. You don't even call their solutions 'idiotic'. You can say: "This approach is completely wrong, here's why and here are some alternatives" as a fairly callous-yet-acceptable response.

Being unduly cold or callous shows a lack of diplomacy, and as Engineers sometimes we are all guilty of that a little bit, but being specifically derogatory is just bad.

More on topic: congratulations to Guido for his contributions. None of us can never know how hard that was, and how much his contributions have helped so many.

Bravo Zulu.

I wish someone, in some respected 'institution', would give him some kind of medal, or the like.

> if he limited his responses to “this is a bad idea” or “this isn’t done right”

And then people keep wasting his time insisting on a bad idea

Cultural differences and all that. A good 'perkele' will be enough to get the point across in most cultures, even if some leave a bit disappointed.

It is easy to filter such people out. Especially if it is email the sole medium of contact.

You want him to spend some of his time maintaining a block list of his professional volunteers that sometimes have bad ideas?

How long do you stay on the list? And doesn't this assume that every idea that person has is bad? What happens when some good ideas are caught in the net? (And what happens when someone goes off and grabs help to implement the bad idea, because you weren't there anymore to tell them again not to do it that way? Or worse, what if they come around to your point of view, but can no longer reach you?)

Wouldn't it be better to just say no, emphatically, and in a way that is clearly and unambiguously no? (I don't think it absolutely has to be a personal attack, but at least it's not passive-aggressively putting your ideas into a blackhole echo chamber...)

I agree you, I assumed an incompetent/malevolent/sociopathic contributor that everybody would want to avoid. A toxic person that is.

In the case you talk about, I think it's easy and effective to put forward one's thoughts with simple, clear language that's formal enough for the public mailing list of one of the most important open source projects on the world, in all of computing history.

We tend to think in extremes: either be "PC with sugar-coated words" or insult people for their defects in public. No, there's a middleground where one can be an effective maintainer and still possess some humane virtues. Simple: you bring me some code, I find it dumb, idiotic, or what not; I have two options: I can tell you that the code is buggy/mistaken/&c and either reject it or request improvements (remembering also nobody, including me, is born an expert, and lives without mistakes); or I can tell you that you're dumb, tell you to fuck off, to shut the fuck up, and maybe insult your family. I'd guess you'd rather want to face the first way of communication.

If a person can not communicate, they should not be a core developer of anything anyways. Teamwork is 80% communication and 20% actual technical work.

You don't say it out loud ("fuck off and die"), but when you exercise a block list, or mute or ban someone on a board, the net effect is the same. IMHO actually it's probably much worse.

Sure, maybe egos are bruised, but nobody's contribution or community standing is actually harmed by "fuck off and die."

A person who is banned, on the other hand, has no choice but to basically "fuck off and die." You think you're making the board more polite, but actually you just told that guy overtly through a policy enforcement action that his ideas or person are so bad that the ideas are not worth reviewing anymore.

OK, I agree with you too, in principle at least, I would rather not be on the receiving end of the "fuck off and die" and I wholeheartedly agree there's a nicer way to say it. But I hope I'm being clear, that personally, I'd really have rather you just told me to fuck off and die.

The block list was your idea now, and I think I want to dwell on it, because I don't agree with the premise that there are toxic people to merit the existence of a block list.

> And then people keep wasting his time insisting on a bad idea

You said it yourself, "one of the most important open source projects in the world" – Linus is much more successful than you or I, so we can afford to be charitable with our words and our time. I'll defer to reserve judgement on Linus because right now we're still talking about how you handle people with bad ideas. I want to say my feeling that you must not do it with a block list.

The banned person is no longer able to provide any further benefit to the group. Maybe you have an actual toxic person and you find yourself in a position to ban them, ok go ahead and do it. I hope you won't misuse this authority to ban someone unfairly whose ideas are simply very bad.

But let's say you ban someone and actually misjudged, and it wasn't really the person that was toxic, just the idea; the contributor with bad personality or ideas can probably still be rehabilitated in the group! But first they must admit their mistake, or at least receive a stern admonishment.

So let's assume, charitably for Linus again, that it was actually a toxic idea that provoked the "fuck off and die." I prefer not to admit that there can be any toxic people until it's absolutely necessary. Maybe he is toxic. I am not in a position to ban, block, or kick him, (or anyone else,) from anything. So I'm not sure it could matter if I was to come to the conclusion that he was toxic personally, obviously you're free to argue that or not.

All I'm saying is that once you admit that both people and ideas can be toxic, it's very easy to make this mistake. So I'd prefer to grant that people are not toxic as a rule until it's a proven fact that simply can't be discarded.

I guess I have failed to explain myself: I think bad people (trollish, insistent, selfish, &c) can be banned, and that is more effective than insulting. Bad ideas on the other hand, should not get people banned, but criticised &or refused in a clear, non compromising manner.

No I don't think you have failed to explain yourself, but I think it's quite possible that we still have a fundamental disagreement about how liberally and when to apply bans.

I don't agree that we were ever talking about bad people until you introduced the notion, and the conversation does not need to be about Linus, but if it was... he is not accused of chastising bad people, he's chastising people with bad ideas. You suggested that he filter them out if they persist, and I basically equated that kind of filtering as like a ban, that I would never use as a community leader.

I'm sorry internet stranger, but I don't feel confident in (your or my) ability to effectively distinguish objectively between a contributor who is (trollish, insistent, selfish etc)... vs one who is being (persistent, uncompromising, a bit stubborn, maybe snarky once in a while, or playing devil's advocate for argumentative purposes, etc.)

Those adjectives can convey opposite subjective opinions in the same objective reality, and the side you choose to be on may depend on simply whether you like the person or not. Is it a ban-worthy offense or is it exhibiting decisive leadership qualities? Well I think that probably depends on whether or not you'd be the one laughing if I said "fuck off and die" just one more time in this thread. You're arguing in good faith but I still disagree with your conclusion.

We're arguing a hypothetical so I'm not sure either of us will convince the other of anything, but here's my piece.

Five comments ago, you suggested filtering people who annoy you with their persistent bad ideas in a professional setting, and I've done all I can to argue that it's not a strategy that will ever work for Linus, and it's not a good strategy for either me or you, you should not consider it.

"Go to HR" is the strategy for dealing with bad people in a professional setting.

If someone's ideas are bad, you should not exile them from the community for it, obviously. If you're serious about leading in a community, ask yourself if you'd be willing to "walk this person down to HR" before you consider waving around a ban hammer or filtering them out and ghosting, because that's exactly like what you're doing.

Linus is not leaving LKML, and that's another topic. You'll have to filter his mails if you find him offensive and you're on the LKML, let me know how that goes for you.

You could also try to read past the insult, and divine the point that was intended to be heard, and take it to heart.

An insult from Linus is like a blessing. He just doesn't give them to anyone. But I'm not here defending Linus.

We disagree indeed, and that was foreseeable. I just wanted to clarify my words.

I'm not on the LKML and most probably won't ever be. But I generally say a word or two about Torvalds' behaviour because he is a "role model" for upcoming (and current) F/OSS maintainers, and I doubt he is a good one for these growing communities to be healthy places. If he is fine, and his peers are fine, I don't actually care about them as long as they are pushing bugfixes to the kernel.

I'm not familiar with these specific cases but I do think that many popular open source authors are extremely rigid and uncompromising. And yes, personal attacks against prospective contributors is a very harmful thing for the project. There are nicer ways to reject PRs and proposals that don't push away contributors.

Also, I'm a firm believer that very talented people can make very silly mistakes sometimes so you can't assume that someone has no value for your project just because their work or idea was disappointing on a single occasion.

When open source project leaders show aggression towards well-meaning people, it's a blatant display of arrogance and egomania.

As an outsider: It's fun.

Software construction shouldn't need this level of drama or comedy.

It almost feels like hero worship.

Every other industry has “celebrities”, or otherwise popular/infamous professionals, why should software be any different; because it’s more pure?

Open source projects needs someone to bring down the hammer and have final words, or else it will slowly descend into bikeshedding hell where nothing gets done. I fear for the future of Python.

What you say is totally different from and possible without insults.

This whole industry shouldn't need this level of drama or comedy.

Drama and comedy can be fun, and it's human, after all. Toxicity is not good.

Or maybe Linus isn’t afraid to say what’s on his mind, and that’s why people respect him.

You should try it some time. I know when I started doing it on here, my karma plummeted (real world analogue is “reputation” or social standing). But at least my conscience is clear.

There is a difference between speaking your mind vs berating or insulting people.

He just said what was on him mind. Clearly and unambiguously.

Why not? All work and no play ...

I prefer nonviolent work and play.

I also prefer people who role model nonviolence for future developers.

I don't see violence there.

Violent communication is any kind that may stimulate pain in others. Insults, criticism, and judgment are examples.

Then there is no need for communication at all. I mean if you can't even critize ... it reads like some "Safe-Space" BS.

I'm not saying violent communication isn't allowed or is wrong. I'm saying a culture that protects its usage and normalizes it is unsustainable. I prefer to strive toward minimizing its usage and cultivating cultures oriented around everyone's physical, emotional, social, spiritual, and mental well-being. Establishing nonviolent communication as an explicit cultural norm is a step toward that. Same goes for community accountability practices and transformative justice practices, which aim to help individuals and the collective by analyzing systemic cultural components to see how sustainable they are.

Torvalds is pretty sustainable though. Since 1991 he's handling it. He also explained on why he needs to use aggressive language, can't find the source though. He said that unless you put some really strong words into a person, they won't stop with their (wrong, bad) project and get sad when it's rejected after they finish it.

Well, you get physical well-being for free on Internet discussions. For the rest, I don't know. People get triggered over harmless shit so often, I just shake my head for such stupidity. You mentioned spiritual well-being. I contradict and say that if I disrespect your religion (not you as a person) and you get triggered by it (love that word) it's entirely your problem.

But my Internet communication experiences also include games, so these words are not even the worst you could hear. With that in mind, the above pretty much applies all the time.

Physical well-being isn't free on the internet, since every aspect of well-being can be affected by every other one. Chronic emotional stress has physical effects, for instance. Bullying can impact each aspect. My spiritual wellbeing isn't about religion. It's about what the quality of connection is between myself and others. I prefer peaceful connection and hypothesize it's healthier for me in the long-run.

I'm right there with you that if someone triggers themselves over my words, the triggered person is responsible for how they react/respond to it. I also choose to share in the responsibility because whether I intended for that outcome or not, it still happened as a result of someone's personal state encountering my words/actions. I aim to respond compassionately to them and hopefully empathize with where they're at in a way that invites healing around both them triggering in the moment and whatever they're carrying from the past. I view this as my responsibility because I've learned how to heal around several of my own issues and wish to help others learn how to heal themselves.

By doing so, I can contribute to cultures in ways that promote wellbeing beyond the context of whatever we're coming together to do.

Also, Linus's behavior isn't the only way to operate and his goals can be met in other ways. Him doing this since 1991 doesn't necessarily mean it's a sustainable way to be for him... It simply means his behavior doesn't outweigh the usefulness of his contributions, yet.

Any example of being brutally personal? There's plenty where he attacks someone's work and mentions their position in the community but I don't think I've ever seen him get personal, like insulting their looks or background.

There's nothing personal there, it's a generic insult. Unless Linus know's about the persons breastfeeding history of course.

My understanding is that the person being derided here isn't even a kernel developer.

  $ git shortlog -s --author Sievers --before 2012-07-06
     339  Kay Sievers

  $ git shortlog -s --author Sievers --after 2012-07-06
      12  Kay Sievers

That specific dev was completely banned from kernel development four years ago (two years later): https://lkml.org/lkml/2014/4/2/420. I don't know the persons involved and how much they contributed, but I'm wary of the implied cause.

I think it's related to this [1]. The tone of the conversation is unbelievable, is it normal to have this kind of flame wars on kernel?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=76935

Its not a like a workplace where the boss can just say "we're going this way". If two parties disagree then the standoff has to be broken somehow. Getting angry isn't always the most effective approach, but it does remove ambiguity about how much a person cares about the issue.

This is laughable. What would you consider a "personal" insult?

Something personal to an individual, insulting their looks, background, family, etc.

If you call me a dickhead it's not a personal insult, call me fat it's getting there and when it's that [redacted] event when I was drunk a few weeks ago it's personal.

Anyone that find that Linus spray as "brutally personal" needs a cup of cement.

If you showed me the sentence "If you call me a dickhead it's not a personal insult" removed from all context I would immediately know that it could only have been posted by a brain genius at Hacker News.

> I would immediately know that it could only have been posted by a brain genius at Hacker News.

Have you ever worked or even associated with people in the blue collar world? Dickhead is tame enough to call your friends. Ever watched Gordon Ramsey? He might have better writers than most chefs but the abuse levels are industry wide.

Dude, when you're in a hole, stop digging.

Since the people that enjoy arguing semantics and splitting hairs love a good "word definitions" argument, let's take a quick look at "personal". Merriam-Webster suggests "of, relating to, or affecting a particular person".

So, let's ask ourselves, is the term "dickhead" personal? Does it relate to a particular person? I don't see it relating to anything else, so I'm going to go with "yes" on that one.

But I could be missing something. What do you think it relates to?


> 2. of or concerning one's private life, relationships, and emotions rather than one's career or public life.

A much more relevant definition in this context don't you think? It's their public work being attacked, not their private life.

There are plenty of people who don't like being called dickheads and choose not to work in those environments. I will never contribute a line of code upstream to the kernel, as will plenty more people who are much smarter than I am.

You and Linus and all his fanboys will no doubt say the kernel is better off without us.

>Good writers, comedians or directors know when to quit at the top their carreer.

Actually, no. I know this is getting away from the main point of the discussion a bit. But Adam Savage gave a good explanation as to why most paid people quit at the height of their career [1]. The idea is that once people pass their prime, the work they produce is worth less. So the only way such careers could continue would be for producers to overpay for a product, or for the actors to continue working just as hard for less money.

[1] https://www.youtube.com/watch?v=sGeS6m3hVk8

It is sad but needs to happen with every BDFL, I really like the tone of the email and I am sure the python core devs would figure out something. :)

Finally, Guido if you are reading this, thanks for everything you have done for the language and especially the community behind it. I partly owe loving what I do to you. Hope taking this break would help you be happier.

Yes thank you Guido! I started working with python back in 1999 working with zope, now we live in a much easier world where you have many options to deploy python applications, my boss wound up rejecting my project but working with python was just as amazing in 99 as it is today its just so much easier you can see all the work and more importantly love that has been put into the language since its inception. Thanks again Guido for all your amazing work!

I have really horrible memories of trying to keep a Plone site in prod from my sysadmin days.

I'm also really sad to see him go. I sincerely hope Guido enjoys his well earned time off. I'm extremely grateful for the amazing community he has fostered around his excellent language.

Though as an avid Python user (~10 years), this does fill me with concern. Not only for Guido's health, but for the health of the language. Guido leaves awfully big shoes to fill, and I'm hoping the community is up for the challenge.

Python was my first programming language, ~15 years ago. The bracket- and semicolon-free syntax is beautiful and approachable to this day. Python is my go-to for writing data format conversion scripts. I wrote a random sentence generator in Python 10 years ago that gave me and my friends hours of entertainment.

Thanks, Guido, for the good times!

I can never get into Python and end up with as much passion as you. For me, its a very powerful and useful language - no doubt about it.

But the aesthetics of a whitespace language just don't jive with my 30+ years of experience writing code. No matter how many times I try over the past few decades, I just can't get passionate about writing Python code. I know its power, and I totally grok its value to our industry - but for me, Lua is just far more elegant, even if it doesn't ship with all of Pythons' goosebridles. Lua is my go-to scripting language; I only ever use Python if I have to - i.e. its enforced on me by others.

I really do try to get over this personal handicap, often enough, but the moment I have to start thinking about indentation I just lose all the passion and it starts feeling like a drag. What a dilemma, because I know it has been used for many, many great things .. I just wish I could get over my aversion to white-space'ing things all the time. I've tried editor after editor (well, expect the Python-specific things), but it just doesn't click.

Ah well.

The indentation should be almost the same as any other language. Unless you have an aversion to consistent code-style.

Python whitespace was only annoying for me years ago when it still had trouble handling tabs and spaces in the same file, and you would run into literally invisible bugs. I haven't run into that in a long time, though.

It's also basically impossible to cut-and-paste code from a web forum. Was that "else" from the inner or the outer "if"?

That could be considered a feature. At least you have to read what you have copied and pasted.

That's cute but I hope no one reading this thinks you are being serious. If they do, to wit:

So many webforums strip leading indents from code. It's not like it looks right on the forum, and then gets inserted into your editor wrong. It's often not right on the source side either. So if you're trying to learn an algorithm from the Python code, you're SOL. This has happened to me.

It isn't cute at all and I am quite serious. It is an accident that Python syntax pitted against sufficiently unsophisticated code displayers causes copy n paste breakage.

However, that breakage does mean that you have to at least read the code a bit. You either get to avoid a potential security flaw or gain a deeper understanding of an algorithm.

Fixing syntax does not break your ability to learn an algorithm but it will get you closer to its description.

With Python you are generally SIL not SOL.

You're not SOL. You just have to retype or reformat the code. Given that you're trying to learn, you should have started with that step anyhow.

I've been writing Python for years and never had this problem.

I find this hard to believe. Searching for python copy paste indentation, the first page of results has everything from how to turn it on for various editors to how to turn it OFF for various editors (implying it's built-in to some). If you just gave up 5 seconds after pasting because it didn't look right or work immediately and you didn't even try looking for help... I dunno what to say.

I would suggest this is more of a forum software problem than a Python problem. Stripping indentation damages the readability of code in any language.

How so? If the code was properly indented on the forum, it'll still be properly indented when you paste it. The only thing you'll need to do is to make sure that indentation of the entire pasted block is consistent with whatever's around it... but pretty much any editor these days, at least the ones meant for code, let you easily adjust indentation of an arbitrary selection (just highlight and Tab or Shift-Tab as needed).

Also makes auto formatting very difficult when whitespace indentation doesn't just affect readability but syntax.

Use black. It just works.

I have problems in a lot of languages copy-pasting code (why are the line numbers being copied!?), but yes this is another problem for this specific language.

What editor are you using? This just works in VSCode, vim, TextMate, etc.

Make sure you copy the whitespace on the first line as well and then it's just a case of indent/dedenting the whole section of pasted code to match.

yes, but that's so minor compared to the gain of a more readable syntax... really an edge case.

tabs would be much better, but unfortunately pep8 dictates spaces.

For submissions to the language. For your own stuff, knock yourself out and tab away.

Python has open-braces in the form of colons. If you use emacs, you can use the PASS statement as a close-brace and everything will auto-indent properly. Python purists have conniptions when they see this programming style, but I've used it for nearly 20 years and it works for me.

I usually close blocks with "#end <whatever>". It doesn't automatically format, but it at least makes it clear to me should the formatting get messed up. I keep thinking about changing the emacs mode to respect this, but it never causes enough of an issue to make me do it.

I found Python's indentation style more appealing after working with Clojure for a while. Python is a bit like lisp without the parentheses. In fact you can Clojurify Python with Hy (http://hylang.org) which solves both the indentation problem and the crippled lambdas problem.

Python is nothing like Lisp, where did you come up with that?

Three things that are key in Lisp: Symbols, environments and lexical scope. Python has none of these.

Most of the examples of Python program design that are held up as "Pythonic" can be described as Fortran with dynamic typing.

Python reminds me more of an object-oriented BASIC. Mostly imperative control flow. Lots of assignments. Lots of state manipulation.

Perhaps the biggest computer science cluster-fuck in Python is that there is no syntactic distinction between instantiating/binding a variable and assigning to it.

Python 3 makes it worse by adding some declarative stupidies nonlocal and global:


> but for me, Lua is just far more elegant,

It's curious... Lua is my favorite language due to its elegance, but I would love it even more if it used significant indentation (using tabs, of course) instead of "end" blocks.

OTOH, I would love Python even more if I could do:

    x = function(x) return x*x end
and not use those awful Python lambdas...

Not that it really matters though, bridges still get built.

    x = lambda x: x*x
It doesn't look that bad in comparison...

Your example is already doable without lambdas:

    def f(x): return x * x

To clarify: the point I was trying to make was that the explicit 'end' in Lua allows for closures that are more nice (subjective) than Python lambdas. Something both JS and Lua got right, but with which Python ended up with a much more limited syntax.

The lambda syntax is not what makes it less nice - it's the fact that they are limited to a single expression. Being indentation-based has nothing to do with that restriction: Nim manages to use indents and to have multiline lambdas at the same time.

it looks a bit perverse to use the same name for the function and for its argument, but maybe it's just me

Lexical scope, I like it

You can try moonscript. It compiles to Lua and uses significant indentation.

I used to have a similar aversion to significant whitespace having learned in compiler classes that space should be insignificant. Over time I learned to appreciate the significant indentation though and now I want a C frontend with similar syntax.

Try Nim, pretty much a Python-esque front-end for C.

Personally I really miss defining for-loop index cars in the for-loop syntax.

This is way off topic, but I’ve never seen the word goosebridle - googling it comes up with a phrase a wigwam for a goose’s bridle - and there its usage is meant as a rejoinder meaning “none of your business” - I’m curious how it ended up as a word to mean - I’m guessing - flashy features (jeez now I am sure there is a more common word for that) - is this a local thing, or is the etymology on the web wrong, what I’m saying is I’m curious how your usage of the word came about :)

I haven't used Python in many years, but it was the first programming language I really could say I loved. Everything was was either completely in tune with my intuition or well-documented.

I had a lot of fun with Python, and I learned a lot about programming by (ab)using it. I am very grateful to Guido van Rossum and the work he has done, and I wish him all the best for his future.

I totally agree with this. In 1999 I had only used C and shell (well lisp a little bit in college), and python was such a breath of fresh air...

Even though I am hardwired to C and 'thinking like a machine would/prefers', python was probably the first and only language I didn't feel like it was a programming language at all. Always when I write something in it, it's always 'huh, and that's it? I'm... done?'. Sure, it's equal part due to language and 'batteries', but neither would happen without GvR and awesome community that built around his project and him. Python, to me, is like lisp without parens and with libraries - the future we were promised. Only thing I, personally, can't do is write large(er/ish) codebases with it. I tend to get lost, but that's probably due to my C-like brain. In any case, thanks for everything!

how is python like lisp?

The future we were promised when we bought into what lisp would/could be, with all the practicality we see now in python. Norvig wrote about it more here: http://www.norvig.com/python-lisp.html It was from that article when I gave python a serious try and it stuck with me as a go to language for all the small things one does often, but also exploratory programming as well (with iPython/jupyter).

have you ever tried f#? if you think python is what lisp could be (a little confused by that...see racket...but...), then i am curious what you think about something like f#. it’s like python in a way, in that it has oop and uses indentation and not brackets, but it is so much more. and it’s more regular in its semantics. everything returns a value.

"The future we were promised" sounds like he's talking more about a combination of ergonomics and productivity that were promised by Lisp but it never got there because the community just didn't expand to the same size. Python is so widely used that the combination of adoption and design decisions is in the sweet spot we were "promised" by Lisp advocates.

F# could also play that role since it can access the rest of the .Net ecosystem but for Python is more approachable as an OOP-ish language.

You're exactly right about what I've meant. It's not only about the language. In fact, I'd argue it has the least weight of all of the variables. There are various nice languages (to use) which just aren't there regarding publicly available knowledge, libraries, tools, manpower, etc. (lisp', scheme, d1, Ada even...). Python, while not perfect, sits quite comfortably where you could say it has it all.

you can program f# fully as an oop language, where i think it is still more approachable than python for that. add in async, first class events, tasks, observables, etc., and you have a very approachable but high ceiling with f#. and the syntax is still cleaner than python.

If you like F# but wish you could leverage the Python ecosystem, then try http://coconut-lang.org

It's lisp without the curse. You have an arbitrarily dynamic runtime but enough structure and cultural idiom against abusing it that it has flourished. Compare for example type annotations in python versus those in clojure - clojure's expressivity and the culture's tendency to use it pervasively make meaningful annotations much more difficult than in python, even with python's crazy calling convention. Additionally a lot of my data processing python code winds up feeling very lispy - arbitrarily deeply nested iterator pipelines transforming dumb and often immutable data. We largely do this in python because smart objects are slow not out of any pursuit of purity, we have a thriving ecosystem of these kinds of libraries, but the end result feels vaguely similar either way.

Python is nothing like Lisp, please stop with the generalizations. When it comes to stupid comparisons, Ruby is more Lisp than Python, at least it's got Symbols.

Python is not homoiconic, it doesn't have {reader/compiler/normal}macros, it doesn't have symbols, it doesn't have proper lexical scope, it doesn't have dynamic scope, it doesn't have conditions and restarts, not every statement is an expression, it's full of special cases and is monstrously complicated if you look beneath the surface [thus all the hacks in PEP form].

How is it Lisp when it doesn't have the special magic that makes Lisp so powerful?

Python is an object-oriented BASIC.

'Basically, Python can be seen as a dialect of Lisp with "traditional" syntax'

-- To quote Peter Norvig, Director of Research at Google and author of multiple books on AI and Lisp.

norvig is the only one anyone ever quotes for python vs lisp. he is beyond my knowledge, but i just cannot see what he says in this quote. python doesn’t feel like lisp at all when programming in it. the mindset is completely different.

edit: i thought this quote was much more recent. it was from around when he first joined google or even before.

That wasn't his motivation for using Python.

His motivation was much like many others -- it's the language that looks closer to pseudocode than any other.

His first attempt at doing the AI book using Java was a failure because it's verbosity and lack of features. Students found the Python version much easier to comprehend than the Lisp one.

> His first attempt at doing the AI book using Java was a failure because it's verbosity and lack of features. Students found the Python version much easier to comprehend than the Lisp one.

Sigh. Is that the nature of the beast in lisp? To me, it has always been a difficult language to sell to more "traditional" minded devs.

See Hy - a lisp written in Python (http://hylang.org).

Even though I write python only if it’s going to be like 200 loc tops, it’s insane how gracefully the language has aged. It came out in 91, thus predating for example Java. Fun fact, I believe the very first google scraper was written in it.

At the same time I can’t wait for the next language to replace it.

People often don't realize this. We hear a lot that python is moving too fast or too slow. To say that disregard the delicate balance the language had to dance on for 20 years. It's crazy.

Agree but it’s closer to 30.

28 if you want the exact number. :) Guido started developing Python in December 1989 and went public with it on Usenet in February 1991 (Unicode 1.0 was standardized in October later that year to give perspective of how far back that was in the tech world).

>Fun fact, I believe the very first google scraper was written in it.

Fun "fact": I need to check my facts, but it could be that the very first Google was written it it, too :)





That’s what he said :-) (first google scraper = scraper used in original google implementation)

Okay, I thought he meant a product that scraped Google sites.

Python hasn't changed much, but the world around it has. For better or worse, when jobs in the language were few and far between, it was a friendlier and less competitive community.

Wasn't the first Google scraper written in Java? I saw an old Usenet post by Page from about 1997 asking about user agents in Java.

Perhaps that was the second scraper.

> Perhaps that was the second scraper.

I believe that is the case yes. However correct me if m wrong.

Yes, Larry Page’s first crawler was in Java, and Scott Hassan rewrote it in Python.

From https://www.vanityfair.com/news/2018/07/valley-of-genius-exc...:

> Scott Hassan: In the fall of ’95, for some reason, I started hanging out with Larry in his office. . . . At the time, Larry was trying to download a hundred pages simultaneously. And I was fixing some of the bugs that he was having with Java itself, and this went on for weeks, if not months. And I remember thinking, Wow, this is insane!, because I was spending a lot of time fixing this underlying tool. And so one weekend, I just took all his code, I took his whole entire thing, and threw it all out, and rewrote the thing that he’s been working on for months very quickly—over a weekend—because I was just sick and tired of it. I knew I could get the thing working if I used a language I knew very well, called Python. I wrote it in such a way that it could download 32,000 pages simultaneously. So Larry went from barely downloading a 100, to doing 32,000 [pages] simultaneously on a single machine.

32,000 pages simultaneously - in 1995? Async has only recently been added to Python, no?

Doesn't select have a maximum of 1024 file descriptors it can handle at any one time? Or some such?

By default, yes. But it can be increased. See limit(1) and ulimit(1).

is that a fact or are you guessing?

select doesnt scale well.

Using threads maybe? Id be curious to see how you would achieve that in Python easily back in 1995.

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

PEP 572: Python assignment expressions has been accepted


Is the final syntax := surrounded by parenthesis?


If the PEP that's published is final, then it only requires parens in certain context to make things clearer, like on the right side of the assignment statement.

Yeesh, that’s a sad thing to burn out over. Python made this decision to avoid assignment expressions a long time ago and has done fine without this capability. Why not just leave well enough alone? Adding a new variation to assignment syntax (just because of the opinion that = vs == is too confusing (even though C and Ruby and many other languages deal with it fine)) is just going to add more confusion to the language. For a line saved here and there?

I had the same gut reaction when I heard the PEP even exists. But now I actually read the PEP, it's very well written and makes a reasonably good case that in specific scenarios it will be an improvement.

(My second gut reaction was it should have used `as NAME` postfix syntax. The PEP debunks that too. Turns out it previously proposed that and the switch to := was a major improvement :-)

The bigger question is whether the gains justify making the language larger... That's subjective, impossible to settle by debate, and the kind of thing a BDFL can help decide one way or the other :-)

It's going to be very interesting to see if things like:

- pattern matching

- inline exception catching

- path inclusion in the built in

- more functional tooling

- lazy keywors

That were BDFL-blocked, will go back to be debated in the mailing list in the next months.

And if yes, will the community stands by its root or create a new era ?

The consequences of which we will only really see in 10 years.

Guido as done an incredible job at being the boogie man, keeping the language simple and readable. It's a hard job.

Can we pull it off ?

The big one I want to see, because it's one of my biggest frustrations with Python, is to finally make lambdas work like every other contemporary language instead of being inexplicably limited to a single expression simply because Guido couldn't come up with a syntax that agreed with him.

There's so many cases (arguably including the problem this PEP was designed to solve!) where having a real inline closure is just far more readable than having to arbitrarily break every single thing that happens to need 2+ expressions out into named blocks out of sequence.

Other things in Python are either simply a result of the language's age and history, or have real technical pros and cons, but that one irks me because it's an artificial limitation chosen for no reason except aesthetics.


God please NO!

I would KILL not to make that happen. So many devs abuse those in every language that has that. Even lambas get sometimes abused in Python (and I have a few examples in our codebase unfortunately). Expanding lambdas' scope is the LAST thing I want in Python, this would just lead to worst codebases, with nearly 0 benefit.

If you want to do something that needs 2 expressions, just create a goddamn function and name it for god's sake.

Sorry but I had to say it, I think the lambda limitations is one of my favorite feature in Python.

It's useful to be able to give names to things and it's also useful to not be able to give names to things.

It could and could also not be useful to give names to all the subexpressions in the following

w = a(b(c(x,y),z))

You could impose a limitation on how many function can be in a single expression, forcing you to give names. That's analogous to your favorite feature, no?

I read a long time ago and was convinced that no nice lambdas was one of the biggest problems in python, but that poster argued convincingly that it's an unavoidable consequence of the meaningful whitespace. Are you proposing a special syntax for multiple statements on one line for this?

I think he made a right call blocking all of those. There are Pythonic ways to do all of those already and the mantra there should be one and preferably one way of doing things is important for the philosophy of the language.

With PEP 572 it wasn't like that. There wasn't a Pythonic way to do list comprehensions which used the same expensive to evaluate expression two times in it and it was I think the only glaring syntax weakness in comparison to languages which have a way to do that (like WHERE keyword in Haskell).

Whats the pythonic way to do dependencies? pip? pipenv? virtualenv? pyproject? And how about Python 2 and 3?


But seriously, I think there's no one way to do things anymore especially if it holds up productivity and effectiveness. Let the pattern matching begin.

pipenv for applications with module dependencies :)

You can in fact factor out expressions in list comprehensions, like:

    [foo(y, y) for x in xs for y in [f(x)]]
Is this Pythonic? Perhaps not, but mainly because multiline list comprehensions are frowned on in general. I think people tend to get too dogmatic about that.

What's the Pythonic way of pattern matching?

There is none in the language, and no proposal has gain much traction on python idea.

A dictionary of string: functions I guess? Don't think there is a decent one

That's parametrized jumping. Pattern matching is parsing a structure with variables and filling those variables from a single structured value.

Python does that with tuples:

    a, b = b, a
But it just stops there. To be fair, I don't know how much power it would gain by going further either. Never made that question.

That is more commonly known as destructuring. (in python and javascript at least, as well as a few others iirc)

Pattern matching is normally (in functional languages like Scala and Haskell anyway) defined as a way of taking a union type and handling each one safely. It's a sort of functional alternative to polymorphism.

That is, polymorphic code

    class Dog(Animal):
        def make_noise(self):
            return "bork bork"

    class Duck(Animal):
        def make_noise(self):
            return "quack"
would, with pattern matching be (in pseudo haskell I hope)

    make_noise :: Animal -> str
    make_noise Duck = "quack"
    make_noise Dog = "bork bork"
In other words, in an oop style you delegate to the object that it implements all methods. Whereas with pattern matching you can have a type delegate to each of the functions that can operate on it to handle it correctly. (This explanation is a disservice to functional styles, its a lot more elegant than what I describe if you do it correctly).

So basically Clojure protocols? As in, multimethods that dispatch on the type of their first argument?

Except that assuming Animal is a sum type (kind of like an enum), the computer will complain.

So a maybe type (equivalent to an Optional) is simply a sum over just and nothing (the two components). If you fall to handle nothing, the program won't compile.

Animal would work the same way. Add "Cow" as an animal, and your program won't compile until everything sanely handles Cow.

So more like a switch case over a set of options where the compiler prevents you from forgetting any.

Since there is no metrics for that, your entire post, much like a lot of any part of the language design process, is very opinionated.

It's why it's hard.

Please can we have real lambdas? I'd then be tempted to prioritise Python over Ruby.

Multi-line lambdas, I hope!

Excluding the 2/3 debacle, Guido has overseen an incredible progression in Python. It has become a contemporary lingua franca for coding, and the concept of a “pythonic” approach has been hugely influential.

I’m disappointed that he broke Eric Raymond’s rule: “When you lose interest in a program, your last duty to it is to hand it off to a competent successor.”

The email sounds bitter, which is tremendously sad, and I hope that after a break Guido will be able to oversee a more constructive transition.

You've come to the wrong conclusion, he handed things off to the core developers. It's not like there are 45 million people with commit privileges over there.

My guess for lack of successor is that he doesn't want to burden someone else. It's probably one of those things like being a head of state where you don't really know what it's like until you've done it yourself. So people that want to be Python maintainer do so because they don't know what they're asking for.

I saw it more of being that he doesn't want to impose a particular style of governance after removing himself from the project. The remaining devs should run it however they see fit.

I wouldn't call 2->3 a debacle. It brought me along in the end, and I was a huge refusenik.

Background ("PEP 572 and decision-making in Python"):


Well, when he is dealing with arguments as silly as "but we will confuse = with ==) it's not a surprise he is tired and had enough. I just wish he had pushed through C style assignment before retiring. New syntax is ugly and introduces a new operator which basically does the same thing. When I've seen this PEP for the first time I thought he lost his touch after so many fantastic design decisions throughout the years. Now I realize he just had enough.

Thanks Guido for fantastic language. I wouldn't find love for programming if it wasn't for you.

My reaction was the opposite -- I didn't know about PEP572, read it immediately after this retirement announcement. My response was, "where has this feature been all these years?" I'm delighted by the addition -- it removes a lot of "loop and a half" ugliness without adding do loops, it simplifies list comprehensions, it lets you remove opportunities to make mistakes, and it doesn't let you put a single-equals assignment inside a conditional as a typo.

Same here, I often find myself writing a loop-and-a-half and will on occasion repeat expressions to get around extra lines (if I cared about performance, I wouldn't be writing it in Python).

I feel like a lot of the resistance is from people who think this is somehow bad style, because it's associated with a source of bugs in other languages. The same kind of people will argue endlessly against having 'goto' in a language, even when it can clearly make for cleaner code (eat it, Dijkstra!) in some cases.

I think EWD was basically in the right to push hard for structured programming, but I also like Knuth's nuanced take:


Can you explain what a "loop-and-a-half" is in Python?

    x = stuff
    while x:
        x = stuff

On the contrary, loop-and-a-half is intended to avoid repeating stuff outside and inside of the loop body.

    while true:
        x = stuff
        if not x:

GPs example is perfectly valid as well - this is just a restatement of the same logic in a way that keeps the logic contained within the loop at the cost of using a conditional plus a break inside of an unconditional loop. See [0]:

  Another motivating code pattern is the "loop and a half".
  It was once common for processing a file by line, but that 
  has been solved by making file objects iterable; however 
  other non-iterable interfaces still suffer from patterns 
  line = f.readline()
  while line:
      ...  # process line
      line = f.readline()
  or like this:
  while True:
      line = f.readline()
      if not line:
      ... # process line

  Either of those could be replaced with a much more clear
  and concise version using an assignment expression:

  while line := f.readline():
      ... # process line
[0]: https://lwn.net/Articles/757713/

> Well, when he is dealing with arguments as silly as "but we will confuse = with ==)...

You clearly never had exposure to a PHP codebase. If people can trip up, people will trip up.

Guido (along with most core devs) are actively against c-style assignment. This pep was a compromise that Guido felt was good.

But c-style assignment in Python was never going to happen, not should it have.

> The problem with the C-style of assignments is that it leads to this classic error: if(x = 0) {...}

yeah, if you code on 20 years old compilers with no warnings. GCC 4.1 warns about this (with -Wall) and Clang 3.4 warns about this too, without any warning flag.

Not having a problem in the first place is preferable to fighting it with tools. == vs = is a classic mistake that I'm sure every C programmer has wasted some time on. (I'm just undecided if I prefer dealing with this very problem occasionally, or choosing either of the verbosity of := assignments or the non-orthogonality of = assignment statements plus := assignment expressions.)

A programming language and the tools you use with it are tightly integrated: you're never using a language, you're always using a language via a tool. And if all C compilers you might use have warnings enabled for this buggy expression, then there's no problem.

The most important "program" that reads your source code is probably in your brain. You probably have some "tooling" in their that is on the watch for "if (x = y)" and other patterns, but I'm sure you'd prefer to not have to run it.

As another counterexample let me give you "language tooling". For example, write a tool that generates a FFI from $LANGUAGE to C. Is it really so unimportant that $LANGUAGE is clean and simple and easy to parse?

> "The most important "program" that reads your source code is probably in your brain."

Not if you have a good Integrated Development Environment (or IDE for short)! That's an even better "program" than your brain, because it shows syntax errors and other warnings right next to your code. It will literally put little red squiggly lines right under `if (x = 1)` and show the file as red in your file explorer side-bar, and when you hover over this line it will give you a tool tip saying "this assigns a new value, it's probably not what you meant, I can either turn it into x == 1 or ((x = 1)), which one do you want?" That is the power of IDEs and they are amazing. We should consider them an integral part of writing code and not fight them or be afraid of them!

You can't assume that every single person will have a good IDE. And you will be reading and maintaining code written by people who don't. In that case I prefer to deal with a language which guarantees no trivial errors.

I agree with your points about IDEs but alas no such language exists to keep you from simple errors.

I disagree... I don’t really have this problem though. = and == are pretty visually distinct to me. As much as > and < or & and @ (or == and :=).

But the best solution is probably to just drop the = as an operator altogether.

> that $LANGUAGE is clean


No, your using a language, and if you know the language enough you begin using a tool

Well, the best option would be to have := (or any other operator) as C style assignment in the first place. This is huge backward compatibility breakage though so the second best option is to use =.

You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway.

> You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway.

They only did it if the := is at the root level. The following is completely legal:

    if match := re.search(pat, text):
        `print("Found:", match.group(0))

    [y := f(x), y**2, y**3]

Great, I haven't used := thing yet. I think it's more elegant like that.

I think that having strong opinions on how others should be developing software is how communities become toxic like this.

"Shooting yourself in the foot is your fault for not using a linter that detects accidental misuse of assignment!"

> I think that having strong opinions on how others should be developing software is how communities become toxic like this.

Depends on what you think the answer to "is programming an art or a science" is. People who build bridges are absolutely subject to "strong opinions" on how to build bridges. I am of the opinion that shipping software to others when under a contract without using all the facilities available to prevent problems - linting, static type checking, etc - should be considered at best a breach of contract and ideally criminal negligence.

Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself). Cargo culting "best practices" is often useless, and is sometimes used as a crutch by developers who are bad at the much more important and much less quantifiable things, like code readability and architectural simplicity.

Wanting your pet coding preferences to be enforced by criminal law is a sadomasochistic fantasy.

> Thinking that linting and static typing will stop all errors is foolish

Did you reply to the wrong post?

> Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself).

Thinking that putting a seatbelt will prevent death in a crash is foolish, and yet they are still mandatory

that's exactly what I mean. Seatbelts won't save you every time but they save you enough times that they are mandatory.

> In another study that examined injuries presenting to the ER pre- and post-seat belt law introduction, it was found that 40% more escaped injury and 35% more escaped mild and moderate injuries.[83]

I don't know how many bugs can use of all possible explicit typing and compiler warnings avert but I'd wager that it would be at least as high a percentage.

And as a former motorcyclist the idea of putting a seatbelt on a bike is terrifying, but under the umbrella of 'mandatory' I'd have to risk getting cut in half in a fender bender 'because that's how it's done'. If you blindly follow guidelines without understanding why they were put in place and when they should be circumvented you do more harm than good. In this context specifically, a python thread, I've not even found formatters that 'just work' in python to the degree that they do in java - I get and support significant whitespace but that combined with the crazy calling convention frequently lead me to just have to suffix spans of lines with noqa because I'm communicating to the reader something that a dumb bot doesn't understand. And that's not even getting into the heavier stuff, I type annotate everything but mypy is beyond useless for my relevant codebases - it no longer just outputs walls of useless noise it straight up crashes, from the most minimal use of even descriptors much less metaclasses. Tools and policies are essential but at the end of the day humans and situations are still currently authoritative.

Programming languages are not just used for shipping software to others when under a contract. Specially Python, which is often used as a teaching language.

You're right. There are times where being right is absolutely imperative.

Maybe it's a know it when you see it kind of thing. When the debate isn't killing people, it's potentially inconvenient extra coding by a developer, and to appreciate the immense social cost those debates can have.

I feel like you could have written this https://jjj.blog/2016/08/todays-software-is-terrible/

I'm still puzzled to why would a compiler allow assignment in an explicit conditional (outside of loop syntax). It's like a baked-in blindspot that most people just want to ignore for some reason. Some languages actually guard against this well enough (eg Kotlin) and say "don't". Even with guards in place, it's not all that complicated to work around in the edge cases where you might want to do it.

Funny you should mention Kotlin; while I like the language a lot, I believe this particular feature would be of immense help in the following scenario:

Imagine you have a sealed class Foo, with `class Bar(x: String) : Foo()` and `Baz() : Foo()`.

Now, imagine you have a method, returning an object of type Foo: `fun foo(): Foo`

And you want to pattern match on the result of this method:

  when(foo()) {
      is Bar -> ...
      is Baz -> ...
Now, the problem is: how do you access String field x in the first branch? The only way to do it now is to extract the methos call into redundant local variable, and then pattern match it instead of `foo()` directly as I did above.

Now imagine Kotlin had that feature; then we could just do the following:

  when(foo = foo()) {
    is Bar -> foo.x
    is Baz -> ...

In Rust and Haskell you can do:

    match foo() {
        Bar @ foo => foo.x,
        Baz => ...,

One option is match statements. Great way to make this sort of inline assignment unnecessary

Could you please elaborate more on what you mean by match statements? Is it an already existing feature of Kotlin?

Ah, I guess `when` is literally Kotlin's equivalent of match.

What I'm thinking of here is Rust's match statements, which do give you the ability to make use of those intermediary values by making use of Rust's enum type.


I see; I agree that proper pattern matching would indeed solve that as well, as e.g. Scala does.

It's handy in C for guarding parts of the language, as you often have to check return values anyway.

    if(malloc(10000 * sizeof foo) == NULL) {
      // Error processing
    } // No need for an else branch here.

Missing assingment.

    int success = NULL;

    if(success = malloc(...)) {
    if(success = malloc(...)) {
    if(success = malloc(...)) {

That will result in undefined behaviour if the value returned by malloc is greater than INT_MAX. If you really need an integer, use intptr_t. But, generally it makes more sense to just use a pointer.

    char* p = NULL;
    if (p = malloc(...)) {

Because assignment is an expression. It has nothing specifically to do with the position being a conditional.

Conditionals need an expression, and assignment fits the bill, so it works.

> Because assignment is an expression. It has nothing specifically to do with the position being a conditional.

No, but it has a lot to do with the way humans write code. This is the source of the bug, not the logic. eg Why bother having whitespace that the compiler can't use (typically)? Human readability.

The concession to not take into account human failing, is pathological.

The other partial fix is to stop allowing truthy conditionals. Only allow Boolean values and the only time you it wrong is when you’re assigning to booleans.

Why is assignment an expression and not a statement? Why should an assignment evaluate to a value?

Well, if you have the concept of Maybe/Optional, it's quite handy to have a conditional binding as control flow (as in Swift):

    guard let value = myOptional else {
        // Handle absence
    // Use value

    if let value = myOptional {
        // Use value

Read Tim Peter's essay on the end of the PEP 572.

It's very good.


You mean compiler right? The compiler should be warning for things like this, not relying on 3rd party tools.

So, yes, if you're using a custom compiler, you kinda are to blame for shooting yourself in the foot. Just use the official binaries!

Depends on the language. Javascript, for example, would use a linter for this warning.

It's not that easy for the compiler to provide these warnings when the language is interpreted rather than compiled

The compiler can do anything a linter can do. Multi-pass multithreaded compilers are not unheard of. eg While compiling to temporary storage, I do a linting in another thread. At the end, check for successes and move the artifacts into the output directory.

What the poster means is that a compiler may not be as applicable to interpreted languages.

Warnings in Python are very rare, and only for good reasons

Throwing warnings for "common code" would be uncharacteristic.

What do you do if you really do intend the assignment?

(Assume for the sake of argument it’s some more reasonable example like "if (x = re_match(foo, bar)) {...}")

You wrap it in parens to avoid the warning: if ((x = 7)) { ... }

C++17 has if-statement initializers, so you can do

    if (auto x = re_match(foo, bar); x.has_value()) {
(or x.ok() or whatever the name is of the method that tells you the validity of x)

You do "if (((x = re_match(foo, bar))) {...}".

At least the systems I've seen need a extra (()) around = to disable the warnings and notify the reader that you're not just comparing for equality.

Open source burnout is real. I'm sure the allure of giving back by creating something useful fades when people constantly criticize your work, especially when you look at the personal and professional sacrifices you're making to produce free software.

One of the pycon keynotes (by Brett Cannon) was on civility in open source:


If you're a little abrasive (as I am) then I recommend giving it a watch. There's nothing wrong with being right but you don't want to jeopardize the respect and community by not recognizing others in a response.

And even if there were no other reasons for adopting codes of conduct, that would be reason enough.

When I first started getting into programming (was not a CS major in college) everybody said to start learning Python first.

I started digging in and a lot of concepts were easy to grasp and I learned quite a bit until I started doing front-end work and I stopped working with it.

This year, my buddy who got me into it originally, suggested I look at django and I've been having fun with that in the past few months. Made me think about picking Python back up and working with it again as the front-end scene is just so crazy right now.

I learned Python ~14 years ago. I already had decent C, C++ & C# knowledge, plus a handful of assembly languages. I already knew how to program, but was taken aback by how approachable Python was. I can't remember if I started on 2.2 or 2.4, but I basically learned 99% of what I needed to know in the first few days. In the last 14 years, I've written a significant amount of Python, mostly for work (finance/trading). It's no exaggeration to say that my Python apps had billions, even trillions of dollars worth of orders/transactions/contracts flowing through them, and Python was rock solid for me every time.

It's still my scripting language of choice. I'm still more likely to rewrite a Perl script in Python than I am to try and make any significant change to the Perl script. I like the "batteries included" approach, and that the Python devs prefer to add new features via libraries than new obtuse syntax. I think most of the recent syntax changes were well deserved and wouldn't otherwise have been well served by a library (thinks like async, context managers, and going back further generators and the if/else ternary expression).

Also, I'm almost exclusively on Python 3 now. The only real issue I've had is constantly needing to remember how to properly open a CSV file for reading (I really don't know how they let that wart live for so long).

We run django with django-rest-framework in production to provide our frontend app with the JSON api it needs -- it has some gotchas and isn't perfect, but is a treat to work with when you want to split time between front and back work.

> I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

Leading a large open source project must be terrible in this age of constant outrage :-(

It's PHP and not Python, but every time I read something like this from a major open source figure, I always think of this old PHP mailing list thread:


OMG there are some real gems in that thread.

> Escalate? Oh how I wish I had someone to escalate to. - rasmus@php.net

> After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I would therefore like to remind you that rasmus@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf

Shades of:

It often happens that I wake up at night and begin to think about a serious problem and decide I must tell the Pope about it. Then I wake up completely and remember that I am the Pope.

Pope John XXIII

“But, Doctor, I am Pagliacci!”

After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue. I would therefore like to remind you that rasmus@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf


Born in Greenland, that's a first I've seen.

That's a good read. I feel like the "customer is always right" mentality does quite a bit of harm to OSS support.

Also reminds me of that dev (who I can't seem to search up) who had their email printed as part of a open-source software license in a car manual and would get ridiculous email from people who had car trouble.

OTOH, way back, when I had a TV receiver card by Hauppage, and a new Linux kernel broke something, I posted a description of my troubles on Usenet, and within 24 hours, the person who had written the Video4Linux subsystem replied asking for more details (which I gladly provided), and a few days later, the bug was fixed.

That, I think, was the most awesome "customer support" experience of my life. I did make a point of being polite about it, however, which I consider a ground rule for dealing with people, especially if I want something from them.

But it was so awesome to post to a random usenet group about a driver problem and have the person who wrote the driver personally approach you for details. You don't get that with Windows, for sure. ;-)

Yep. This attitude isn't dead, assuming you approach the developer via the right/preferred venue, and are polite, and they are still actively maintaining the project. And it really helps if you give a thorough bug report!

I recently submitted a bug report to a fairly niche OSS package that I use, and within a few hours the author replied (on GitHub) something like "oh wow, yeah that's an edge case but I definitely want to fix it, can you send me the test data you used..." and once I gave him the test data, he had it fixed in two hours and now anybody who grabs the source won't have to deal with that bug.

It was great, and even though I didn't do anything except write up a bug ticket properly (the same way I'd expect anyone on my team at work to do it), the software is a little better now.

I had the same experience. Suddenly Emacs Gnus reader stopped working, about 11:00 on a Friday morning. I posted the bug and had a reply from Lars Ingebrigtsen with an explanation and a workaround by 13:00. I think it was fixed by the beginning of the following week.

My experience of trying to get help from Microsoft on the other hand is, well let's just say not quite so impressive; they kept me on hold for 45 minutes once and never did solve my problem.

Back in the days Microsoft would have amazing customer support. And I'm talking about "API customers", many times I've seen them go out of their way to fix third party programs not working correctly by adapting their platform, it was a very efficient process. I guess that doesn't work as well at their current scale, or they care less because they're not building up market share.

They once shipped my company a custom MSVCRT.DLL to fix a crash bug in a third-party application under heavy load. True, it was a bug in the C runtime itself, but they got us a fix for it about a day after we (along with the third party) got in touch with them.

Just a few years later my team had to contact them for a BSOD that kept happening after one of their patches. We were put off for about a week before throwing our hands up on it.

> go out of their way to fix third party programs not working correctly by adapting their platform, it was a very efficient process

This kind of thing probably doesn't even scale with itself, since there are only so many acrobatics your code can go through before no one can even understand why it's doing something, let alone add new workarounds. So the first K broken programs get special treatment, and the others face a much higher bar to get the same treatment.

Years ago I purchased a motherboard with a built in Raid controller. There were no drivers for it in mainline Linux kernel but there was code for a kernel module on the chipset vendor (Via's) website. The provided code wouldn't compile because there was a bug.

People from Fedora IRC channel helped me live debug the code over irc and we found the bug and were able to get code to compile and my raid controller working. Was an awesome experience.

I used to have similar experience with most of the free source (that, or silence when project got abandoned), until Laravel, where I was yelled at because somebody apparently needed an ego boost that day. I still love the framework, but I don't think I'll be trying to reason there anymore. Still - maintaining projects most of the time is unappreciated job, so kudos if you do it

You're probably thinking of Daniel Stenberg of curl fame:


Ha, hadn't seen that one before. I did enjoy this related post about him hacking someone's Instagram. https://daniel.haxx.se/blog/2016/01/19/subject-urgent-warnin...

> "customer is always right" mentality does quite a bit of harm to OSS support.

It goes both ways. All too often people promote their new library on HN and Reddit, wait until a bunch of people are using it as a dependency, and then abandon it without even telling anyone whether or not it’s abandoned.

Not using toy libraries for production systems is a lesson every young developer learns early on in their career.

Fortunately every young developer is also schooled extensively in telling toy libraries apart from serious ones.

And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system?

Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project?

If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example?

A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.

And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system?

Because they're already the senior. CEO said it shouldn't be that hard, and besides, they only wanted to pay $40K/yr.

> And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system?

Some critical assumptions:

- a more senior dev is available

- has time

- understand the system well enough to judge the impact

- is actually a better developer than the junior (in spite of being older / in the game longer)

> Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project?

It isn't, that was the point.

> If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example?

Some critical assumptions:

- organizations keep a close eye on developers incorporating code under various licenses

- the people keeping an eye on that are qualified to make the calls

- the resources to keep an eye on this are available

> A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.

Sure. But that doesn't mean these things don't happen just about everywhere, many times per day.

It is rare to find a company where all of the assumptions labelled above are true all the time. And that's where the problem lies.

It's a clear case of there being no difference between theory and practice in theory but in practice there is, and rather a lot of it. Everybody knows in theory how software should be developed, but in practice hardly anybody actually does it that way. They're either out of time, options or qualifications (or all three) and they will do the job anyway.

That doesn't excuse it, but it does help you to understand it.

By definition, they aren't though-- for the truly green, that extensive schooling comes from `npm/pip/gem install`ing random packages with implementations they don't understand or can't account for, then having to deal with the fallout in whatever form it chooses to manifest itself. Could be a maintainability nightmare, or it could be losing your job.

My advice to mentees is that if installing a package to achieve x saves (a significant amount of) time/money that outweighs the risks to self/company or has value added by means of product maturity or domain expertise, then by all means do not roll your own crypto, web framework, db connector or machine learning library. But if one is going to introduce dependencies on things as trivial as leftpad or someone's Show HN single-pass weekend hackathon proof-of-concept, they will soon learn why we don't bring toys to work.

Then explain nodejs and MongoDB existing in production systems?

Or did you forget the /s...

> Or did you forget the /s...

Yep. It's been a long day after a particularly long week. I will take a break from HN, too much on my mind. Thanks for the reminder.

Have a great weekend, catch you on the flipside

In what parallel universe are you and how do I find the next wormhole to get there? :)

Well, that people don't do such things is not really the fault (nor problem) of the developer of that toy library, IMO.

Nobody else but you alone can ensure that your project is managed and developed properly.

If you put something out there and no one uses it then fine. But once it has hundreds of commits and issues and over 1,000 stars on GitHub, then I think you have some responsibility to people using the thing you’ve created -- if you’ve been actively promoting it as something everyone should use.

It's a free product, not a child support obligation. Even if you do walk away, it's open source and can be maintained by anybody interested in stepping up. This is the price of adoption, not guaranteed updates for life from the creator.

But I get where you're coming from. It's even worse on Steam, where developers will actually collect money during the "early access" phase and then walk away once a (closed-source) tech demo is half-complete.

> This is the price of adoption, not guaranteed updates for life from the creator.

I’m not saying anyone should be obligated to do free work. This issue is that most people don’t feel comfortable publishing a public fork without the blessing of the creator, or at least knowing the creator no longer intends to work on the project in the near future. So you end up with these situations where there are thousands of people running production systems with unmerged security patches because the creator can’t be bothered to spend 30 seconds to write a one sentence reply to an email.

Short of being in a coma, I consider that toxic behavior.

And just to be clear I’m taking about situations where there are lots of open PRs but no signs of life for months or years on end, not situations where the creator just went on vacation for a few weeks.

eww, that's called entitlement.

no one promised you anything. you merged some code into your project. now deal with the consequences. be responsible for your work.

No they aren’t. The code is open source anyway so if the dependency is important enough for your project, fork it. Or pay for support.

There is a fundamental difference between the extreme of stuff like GnuPGP, OpenSSL and other extreme of stuff someone created over the weekend and was nice enough to make available

I dont want to know, how much of core infrastructure is resting on the shoulder of overworked and burned out BDFL. This isnt a ego complex in most cases, but the knowledge that without someone with their commitment working at the project it will crumble.

An interesting debate: Are _users_ of FOSS "customers" ?

I think "consumers" is the better term.

"This is going to cause us MONTHS or fixing code for no real benefit since this behavior change is arbitrary and seemingly, was made for no reason"

Yeah, tough. Fix your code

That's the attitude some maintainers need in cutting unreasonable requests.

It's hilarious because it's literally a one-liner that Rasmus provided for him.

It's more hilarious because his response to that (basically, "this is tax software so there will be a lot of QA when we make that change") is at least sort of legitimate, but only because his accounting software evidently only works due to undefined corner cases in the underlying platform, and that's just ... wow.

I was on the side of the person giving the - I think fairly legit., bug until I came to, "tax software in php" and then I realized there's nothing really black and white in this world.

Did you catch the part about "it makes you lose faith in the product"? ROFL

I caught the part about, "we have unitialized variables being passed everywhere which should be numbers" and that code, well, smells.

I think the PHP team changing the return value of a function without putting anything in a changelog is a Very Bad Idea and a dev. should be pretty upset about that. Saying that the main dev. is doing this work as a charitable thing is fairly misleading as well.

Buuuuut, I also think passing an unitialized value like that is already a bug in this context given the type of software being created. I'd rather see, "NULL" found wherever than know that it was magically changed to 0 (like they would prefer). I know the dev. said that this is just a formatting thing, but I'll wager they're using formatted numbers for some sort of calculation (inadvertently or not).

Whatever is going on, I hope there was a huge code review and a massive QA effort ( which I also doubt happened), because this is a textbook example of tech debt and the loan shark has come a-knockin'.

I agree with this as far as it goes, but I think @zaphar has the better answer: a tax app should never have been written in PHP to begin with.

There's a fundamental quandary in language design: accessibility to novice programmers and suitability for serious work are in opposition. Novices, being novices, are unable to appreciate this problem.

Oh dude: absolutely agreed on that.

One of the hidden costs when you elect to use a language like PHP in the early 00's is that as they fix the glaring issues in their language and stdlib you will be incurring a continuing maintenance cost.

It's a combination of your choice to pick PHP and their choice to fix the languages warts colliding.

It may even have been a reasonable choice for reasons of time to market, hiring, and other business related factors. But the conflict in this thread highlighted that whoever chose PHP in the beginning did not factor in this hidden cost when he made his choice. The results of that lack of information were predictable.

One of my PHP bug submissions is already in high school. The other is in kindergarten. Thankfully both of them won't see light of day in most applications.

But focusing on PHP is rubbish - you can look at any language and find questionable choices. The moment where we need frameworks to make the warts go away - that's worrying. Same thing with JS really

The underlying platform? WOuld that be Python or the tax law?

I have yet to encounter any user so hostile in my open source projects, thankfully. But when the time arises, the line I have prepared is:

    I'm really sorry you ran into this issue. To make things better,
    I've given you a full refund.

Ah, now I want to contribute to open source community just because I might be able to say this to some unappreciative prick. :)

I'm sure 'endosquid.com' is currently being by hammered by people wanting to find out who was so rude and unreasonable.

Looks like it has been dead for a bit now.

Since 2010, it seems: https://web.archive.org/web/*/endosquid.com

Guess they went out of business before they could typecast all these nasty empty strings.

O_o I wonder how many times I've spoken to someone and didn't realize who it was/how important they were because of the anonymity of the internet.

When I was much younger I started building a ray casting engine. I was having trouble wrapping my brain around how to render the floors so ... I emailed Ken Silverman.

It escapes me now _why_ I emailed him. I certainly had no idea the gravity of who he was (for those also unaware, he is perhaps most famous for creating the Build engine used in games like Duke Nukem 3D). I believe I was under the false assumption at the time that the Build engine was a raycaster (I hadn't played Duke Nukem), and I probably found a personal page of his about the Build engine while trying to solve my problem.

Either way, young me emailed Ken Silverman like it was nothing. He responded! He corrected me about the Build engine, but also proceeded to help describe how to render floors in a raycasting engine.

It still took me awhile more to get the hang of the math, and I believe a few more emails back and forth with him. I feel bad now, knowing now who he was. But I appreciated his help immensely. I think I wrote 3 or 4 more ray casting and tracing engines back then. Some were rudimentary, one was a raycaster but allowed arbitrary 2D level geometry (and even used some tricks to put "holes" in walls to cheat windows and have multiple heights). One was for a code golf competition. And one was _super_ efficient; the math and levels were set up such that 90% of the logic was just binary math rather then having to do the usual multiplications, divisions, and square roots. They're a lot of fun to make and I learned a lot.

Ken, if you ever stumble on this comment, thank you!

I've done nothing worth mentioning here, but I have received a couple emails asking detailed questions about things I'd done and forgotten about years ago or looking for early career advice, and I'm more surprised and honored that someone took the time to appreciate my work than anything.

The best I've gotten are emails asking for permission to fork one of my public Github repos. I was never sure how to respond to those, because... yes? By default?

That’s great. In your naïveté, you were unaware not intimidated by his prominent figure or reputation. I’ve found that some very well-known people and companies are more approachable than one might expect, possibly because people usually assume they will be indifferent to personal communication and don’t try to talk to them.

> Ken, if you ever stumble on this comment, thank you!

His email address takes a very short time to find and he's on Facebook. Just a suggestion: why not send a note and thank him for real? You might make his afternoon a little brighter.

(I'm awful about thank you notes and if you knew me you'd be within your rights to call me a hypocrite, but still!)

When I was 19 I was interning at Google and I got into a mild discussion on a mailing list with Rob Pike. When I went back to school the next semester someone was teaching a class on UTF-8 and I thought the name of the creator sounded familiar.

Thank god I don't have access to those emails anymore so I don't have to endure the cringe.

To make myself feel better, I posit that that kind of youthful arrogance is at the origin of many innovations done by youngsters that didn't know better.

Reminds me of attending a conference and being in a workshop with a member of TC39, the Ecmascript standards committee. I was sitting next to this individual but didn't know who they were. I made the mistake of complaining about modern JS and version splitting. Fortunately, I didn't say anything too harsh but I definitely would have held my tongue if I knew who they were.

I know I've gotten into heated arguments on here or on Reddit with very well-known figures in the tech world without realizing who they are until after the fact. Luckily I don't think I've every argued with a developer about their own product before... that I know of.

i have a great solution: speak to everyone like they are a human being with feelings :)

* slow clap *

“A word aptly spoken is like apples of gold in settings of silver.” —Proverbs

I wrote to Ken Thompson when I was an undergrad doing a history of computing essay. And he wrote back with a potted autobiography! It was probably a bit before email became the scourge that it is now.

The sad part is: I lost the email in a transition from one machine/set of floppy disk backups to another.

It's not the outrage, it's the entitlement. People have always been outraged, the major difference I've seen is the rampant sense of entitlement. I'm not sure if it's a result of bad parenting or something else, but it's slowly becoming a major issue for the entirety of the human race.

I noticed this over the years on a forum I’ve run for over 10 years. Since ads are pretty much dead for small publishers like me, the forum costs me money. But I run it out of charity.

Nothing sucks the energy out of me more than lurking in my forum and seeing users complain about how little I’ve done for the forum. I don’t want to know how many weekend I’ve spent building features for the forum or arbitrating problems between users.

The thing is that these posts of entitlement are a relatively knew phenomenon on my forum mostly in crescendo over the last four years.

I’m pretty sensitive to it now and it’s easy to spot eveywhere. From people whining that free shit isn’t perfect on HN to gamers complaining that a modder charges for the mod instead of doing it for fun.

I think part of the explanation might be the explosion of choice [1]. For better or for worse, the more choices there are, the better people expect them to be to stand out. If you make software that solves a critical problem nobody else's does, I doubt people will feel nearly as entitled about it as about a forum or a programming language or whatever.

[1] https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_c...

I'm in an almost identical situation with an online community that I've built and have continued to work on. Back in the day I could hang out there to relax -- these days it's incredibly draining for me to be around.

Completely agree with you. Heck I realized I have the same entitlement issue after running into 2-3 people who were on higher spectrum of entitlement. I was having issue with their behavior but realized I do the same sometimes. I am trying to balance it out. The sad thing is people are not even aware that they have this issue.

I think social media is responsible for breeding this sense of entitlement among people.

I'm not sure it is social media, rather I think it's the price. Free or very cheap opens you up to a group of people you wouldn't normally have to deal with.

I'm a little confused though, by his feelings here. Why did he feel the need to "fight so hard for a PEP" if it was so controversial, and everyone was outraged?

I do understand people's points about "the age of outrage" and "internet 2018" but still: the PEP wasn't generally accepted as being a fantastic improvement, so why did he feel the need to fight so hard for it?

It was controversial syntax, inline assignment-as-expression. There's always a tension between "keep it simple stupid" and "let's make it better", especially when a large user demographic of Python are non-professional-programmers.

Interestingly, C++ is going through the same process, with lots of great ideas being proposed, but the sum total of them being an even more complicated language (on top of what is probably the most complicated language already).

Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.

> Python 3 breakage and async turned out to be prescient, fantastic decisions.

Python 3 implementation was a step in the right direction, but the decision to allow the old language co co-exist with the new one and to break backwards compatibility between the two (for instance 'print') in places where it didn't need to break makes no sense to me.

A lot of goodwill got burned with that.

I think this was important. The class of bugs it would have created if it had been compatible with the unicode/ascii split would be hideous.

Fail fast. It's better to break right away than having false senses of security. There is always __future__ too.

> Python 3 breakage and async turned out to be prescient, fantastic decisions.

The jury is still out on the Python 3 decision, to be honest. Heck, Python 2 is still officially supported until 2020.

Python 3 adoption is increasing, but the instability and breakage that it introduced caused a lot of knock-on effects throughout the Python community that held it back and hindered its adoption and mindshare. It'll take a while before we can really say whether the long-term gains will make up for that.

> The jury is still out on the Python 3 decision, to be honest.

It's not. Python 3 has overtaken 2 and there is no stopping migration to it now. Python 3.7 is a lot better than 2.7. Just on memory use alone, 3.7 is massively better. Sure, there will be some hold outs on 2.7 for a long time. That's fine.

Also, this is not the say that migration from 2 to 3 was handled well. It wasn't. Python 3.0 should have had backwards compatible features like allowing the 'u' string prefix. Indexing byte strings should have returned length one byte strings. Byte strings should have supported at least a minimal amount of %-style formats. Etc.

That has all been mostly resolved and is in the past. Mistakes were made because, shock, the Python core developers are not perfect and didn't foresee all the migration issues. However, there is no way that we are going back and reviving the Python 2.x branch.

It was touch and go for a couple of years there but yeah, Python 3 is now well and truly over the hump.

The Python 3 Readiness Project now lists [341](http://py3readiness.org/) of the 360 most common packages as Python 3 compatible.

Even that's underselling it really. For example it lists BeautifulSoup as not converted, but the link goes to BeautifulSoup 3.2.1. However, BeautifulSoup4 works great on Python 3. And for MySQL there's mysqlclient and several others, and since database packages usually follow PEP 249 pretty closely its very easy to switch. So in reality, rather than 341/360, its more like "everything worth converting has been converted." Or just "everything" for short.

false imperative => "Python 3 has overtaken 2 and there is no stopping migration to it now. "

this shows a superficial, almost entertainment-industry sort of view of a software development lifecycle..

in the latest Ubuntu Bionic with apps, building right now on a local machine, I see 143 python-xx packages installed and 43 python3-xxx ..

saavy package authors use import future and six to side-step the whole issue, while core maintainers struggle, and outsiders invoke a mob voice

Python 2.7 for LTS

How much momentum was lost in the transition though? I know that with the pain of 3 at the time a lot of people started looking at languages like Go or even Scala.

Python currently still 4th at https://www.tiobe.com/tiobe-index/ . As the most popular scripting language on there by some margin, I'd say they're still doing pretty well.

That's not the point of the person you're responding to. They didn't say that the transition didn't happen. They said it's not yet known if it was worth it. All you're saying is that it happened.

I'm saying it happened and Python 3 is the language I want to use. If you don't do Python 3, you either keep the error prone str/unicode string model or you dream up some way to evolve to a better model. Would some mythical version of an evolved Python 2.x be better than what we have? I mean, how to argue against that? I haven't seen anyone propose a workable migration plan. Python 3.7 is better than 2.7.15 and better than 'tauthon'.

Python 3 avoided becoming what Perl 6 has. That alone is a victory.

Is there even a "production ready" version of Perl 6 yet? It has to be the worst example of production hell for a computer language in history. It's the poster boy for the second system effect.

There has been a production ready version of Rakudo Perl 6 (https://perl6.org) since Christmas 2015. It has been on a monthly release cycle for years, and a 3-monthly release cycle for Rakudo Star, the "user" distribution (with some bells and whistles added).

Cro (https://cro.services) is a set of libraries for building reactive distributed systems. Comma IDE (https://commaide.com) is an IDE for Perl 6, based on the JetBrains IDEA platform, now in (paid) beta.

If you want to keep up-to-date on Perl 6 development, check out the Perl 6 Weekly (https://p6weekly.wordpress.com).

Well, many embedded developers will never move beyond C89 unless forced to do so.

Meanwhile C22 work is ongoing.

> Well, many embedded compilers will never move beyond C89 unless vendor is forced to do so.


Not really, many of those developers do have C99 compilers with partial C11 support at their disposal.

There are almost no vendors left offering C89 only compilers.

I'll probably never switch for personal use. The print statement change is intolerable to me. It would have cost them nothing to just leave the old syntax in. It's supposed to be a quick and convenient scripting language and they're actively working to make it more verbose and less convenient. I also still don't like not being able to use "string" objects as dumb byte containers, like I do with an IRC bot that doesn't crash with an encoding exception trying to write IRC control characters into a text file. Yes, I know I can work around that wrapping everything up nice and pretty to tell python "this isn't a real string it's okay you don't need to throw an encoding exception ssh." I just don't think that's good design.

Syntax regularity is infinitely more important than scripting convenience.

Button regularity on your keyboard is infinitely more important than ergonomics too, right? Anything but a grid of equally-sized squares must be wrong by virtue of aesthetics. Spoken language too: let's eliminate all contractions because they reduce regularity. Let's also make all the speed limits in the country equal at 20mph, because regularity is infinitely more important than convenience.

You should be supporting return being made into a function too, right? That would be much more regular.

Reminder that a guideline of python was supposed to be "practicality beats purity" which is in stark contrast to the changes to print and strings. [1] Reminds me of the gradual shift of the message on the wall in Animal Farm from "four legs good, two legs bad" to "four legs good, two legs better."

1: https://www.python.org/dev/peps/pep-0020/

Are you fingers equally spaced square shape manipulators?

I don’t support having return at all. Statements that are not expressions are a mistake.

Syntax irregularities are anti-practical.

Try Ruby.

Aw, alright then.

That a customer of mine started a web project in Python 2 in 2015 after 7 years since the first release of Python 3 means that the Python BDFL and community managed the process horribly.

Could it be that many vendors still ship Python 2 as default for internal reasons (system-related scripts and what not rely on it)? Macs, for example ...

So you customer, not knowing any better, used whatever was on the machine already. If that's the case, that's really not the Python's community's fault.

They could have used any Python version with one of the many version managers around or docker. I think nobody cares about what comes with the operating system nowadays.

The problem was that after 8 years there were still around libraries and frameworks that worked only with Python 2. That's a huge failure. If developers want to keep using the old stuff it means that the new one is either badly designed or badly managed.

Compare it with Ruby. There were big changes from 1.8 to 1.9 (unicode stuff among the others) and again with the 2.x series. The language mostly maintained backward compatibility and we can still write Ruby on 2.5 with the old 1.8 syntax. Community ported libraries and frameworks, started using the new features and all went well.

Mac probably uses whatever python FreeBSD uses. Most BSDs still use Python 2 by default.

> Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.

A lot of companies are choosing new languages over porting python from 2 to 3.

Name one.

I think it's true, but also a red herring.

A lot of corporate dev environments operate on a policy where you're basically allowed to fix things that sales and customer support explicitly ask to fix, but nothing else. Which in turn means an environment where doing maintenance work that indirectly sustains the software is off-limits. Which in turn means they never ever upgrade the underlying platform (that's off-limits maintenance work), and so they end up on an EOL'd platform. At which point they blame the platform, and announce they're going to switch to something better that doesn't impose this problem on them.

Those types of places were never going to upgrade to Python 3 under any circumstances. They probably would not have even upgraded to a completely-backwards-compatible Python 2.8, if that had been released. So blaming Python 3 is a red herring here.

Google replacing python with Go?

This also isn't really true. Google is certainly replacing certain things with Go. But its not replacing python with go.

I understand that had more to do with their "Unladen Swallow"[0] work being rejected than anything related to the transition to Python3.

Since Google couldn't convince folks to let them make Python faster, they created a NEW language instead.

[0] https://www.python.org/dev/peps/pep-3146/

That has little to do with Python 3 and a lot to do with the scale of Google's services where high performance is really important and where refactoring in static languages is easier.

i don't think you answered "why did he feel the need to fight so hard for it?"


No, the bad decision was treating bytes and strings interchangeably in the first place. 99% of the hardest to fix breakage was due to that, and it was the right call to pay that price all at once.

I think I mostly agree with you, but it can be unclear to programmers (who are after all the people writing Python code) whether they're dealing with a string, or merely with bytes that happen to look like a string, and this causes hassle.

Until way too recently essentially all Python code couldn't handle basic SSL/TLS certificate validation for Internationalized Domain Names. Once you understand what's going on, this situation is a no brainer: In order to connect to a machine named X, we must have turned X into DNS A-labels that we could look up, and we can treat those as bytes. The certificate must have SAN dnsNames matching its names, and those too are written as A-labels. So we can almost just compare the literal bytes (actually DNS A-labels are "case-insensitive" so we need to handle that, and the asterisk "wild card")

But Python, in its wisdom, defined this API to take a string, and strings, as you observe, aren't bytes. So instead of the above unarguable approach they wasted precious months trying to figure out how best to turn the A-labels from a SAN dnsName into Unicode strings, which isn't even the right problem to solve.

Eventually sanity prevailed: https://bugs.python.org/issue28414

The API in 2 is not optimal, but they fixed it the wrong way. As you know, some operations make sense with bytes, and some make sense with character strings. The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding. Then byte-oriented packages (e.g. those that deal with data sent over an interface like a socket or pipe) could simply ignore the issue of encoding. Whole classes of errors would just disappear for many python coders. Other coders, who do care about encodings and non-ASCII characters, would still get those errors but that would be OK because they would know how to fix those errors.

So yes some breaking change was indicated, but the particular change that was made was the wrong one.

Then byte-oriented packages (e.g. those that deal with data sent over an interface like a socket or pipe) could simply ignore the issue of encoding.

Long and bitter experience has shown that people who think they can "simply ignore" the "issue" of encoding actually can't. That mindset is mostly a more polite way of saying "people who assume everything is ASCII all the time, or at most an encoding that always has one byte == one character". Those assumptions break sooner or later. I prefer having them break sooner, because I've been the person who had to clean up the mess at an unpleasant time when it was kicked to "later".

Which in turn means Python 3 made the right choice: text is text and bytes are bytes, and you should never ever pretend bytes are text no matter how much you think you'll never run into a case where the assumption fails.

For lots of applications it doesn't matter how many bytes are in a character, because characters don't matter. Even within a particular application, it's common for characters to only matter in a few particular locations. It would still have been a win for python, to make such applications easier to write and maintain.

Implicitly converting strings into bytes or vice versa means now all your APIs grow an exception "Invalid encoding" / "Can't encode this" / "Can't decode this" / etcetera that you need to deal with.

Making people actually do the conversion has the advantage that when writing their string conversion code they might actually do something with the exception beyond maybe logging it and then pressing on anyway. It also gives you the opportunity to explicitly offer them alternatives like treating everything we can't encode as some sort of replacement character (works well for Unicode, not so much for ASCII), which is way too much to ask of every single function that takes bytes.

...which is way too much to ask of every single function that takes bytes.

Sorry if I wasn't clear. I meant to suggest that the byte-functions wouldn't know or do anything about encodings. They just work with bytes. It's the other functions, that take the encoding-annotated bytes (or optionally a "pure" unicode type), that would care about encodings.

> The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding.

That's the ruby solution. I like the ruby API here. When ruby introduced it in 1.9, it did cause similar upgrade pain, since you weren't used to having your strings tagged with an encoding, and suddenly they all kind of need to be if you want to do anything with them as strings-not-bytes.

As someone else noted would be the result, indeed the result was lots of "incompatible encoding" exceptions.

I think ruby actually has a pretty reasonable API here, but several years on, there are still _plenty_ of developers who don't understand it.

Sure, there are growing pains with any breaking change. Do you think the ruby 1.8 -> 1.9 transition went more smoothly than the python 2.7 -> 3.x... transition?

Sure it did. Barely took a few years, and it also had a large performance boost (whereas 3 initially came with regressions until 3.4 or so).

Plus, basic things like Rails were working from the start.

My impression is that it did, yes.

But on the other hand, Python's overall popularity has grown (mostly on the back of 'data science' I think), while rubies has shrunk, and python is definitely more popular than ruby at the moment... so python's lesser success at that transition didn't actually matter much in the end?

Encodings are related to storage and transportation -- not business logic. You should not have to deal with encodings inside your application, so forcing programmers to deal with encodings at the point it matters, when text enters and exits the application, is thus sound.

If yoy truly don't care whether or not the text is decodable (which is sometimes the case), then don't read it as a string, read it as a byte array.

You can still have methods that are generic over byte arrays and text, since that is an orthogonal concern.

Bad decision? UTF was Standarized in 1993, python was first released in 1991. You can't decide to use something that hasn't been invented yet. Back then bytes and string were the same thing. Java did do it right but by 1995 the industry had already seen the problems of differing character sets.

>Back then bytes and string were the same thing.

No, they weren't. Impossible as it seems, we had encodings (including multi-byte encodings) for decades before UTF.

Python couldn't use UTF-8 in 1991, but it could very well tag strings with a specific encoding, instead of treating them as a bucket of bytes C-style.

>Java did do it right but by 1995 the industry had already seen the problems of differing character sets.

We had seen the problems of "differing character sets" for decades already (Windows vs DOS version of the same language encodings was a classic example for most users, but the problems go back to EBCDIC and so on).

Java just did a more right thing, but we already have a need for generic string types that can handle multiple encodings and know what they contain and how to convert from one to another.

I wish I could sufficiently express my frustration for this. It's such a common mistake too. If you design a language with a type for text, and your language has a type called "string" oh God please God let those two be the same thing.

There are so many languages in which the type "string" is not the one to use for strings...

"No, the bad decision was treating bytes and strings interchangeably in the first place."

Show me the 1995 software that gets this right, and I'll show you proof that time travel is possible, by simply showing you that software right back again.

Abstractly, yes, it's true. Concretely, though, it's not a particularly valid criticism.

> the bad decision was treating bytes and strings interchangeably in the first place

Python preceded unicode, though.

I think there are people on both sides of this fence.

Google is still largely Python 2, but my impression is that Facebook actually managed to make the transition to Python 3 after putting in the right presubmit checks.

For the discussion about Facebook, see here: https://news.ycombinator.com/item?id=17417201

It seems Python 3 is now dominant but not total, according to TFA.

This is a particularly ill-chosen thread to deliberately try to re-flame this flamewar. Most threads are.

Heaven forbid that someone responds to a point made in another post. On a public internet discussion forum. In a discussion about the context and effects of divisive and difficult decisions. /s

Python 3 breakage is basically flamebait by now.

Heaven, sadly, cannot forbid poopy responses but we can encourage others (and ourselves) not to post them.

Notice how you've only added noise in the discussion, and made a casual comment on something somebody wrote a 10+ comment meta-thread?

Plus rudely assigned intentions ("flamethrower" etc) to others?

To be fair, the person stating that Python 3 breakage was a fantastic decision probably should've avoided referring to that as such, as it almost certainly invites disagreement on a controversial topic.

No, that's giving the flamemongers a flamer's veto. It's a perfectly sensible thing to mention when talking about the difficulties of leading the Python project and offering an opinion on how Guido van Rossum handled them. Picking out that one opinion and yelling little more than 'fite me' back at the person is not a perfectly sensible thing.

Then if someone disagrees & an argument erupts, then that should not be surprising - that post is equally as culpable for igniting a well-discussed issue by posting something clearly so opinionated/leaning towards one side of an issue that at this point one should have known better than to even allow a conversation to digress in that direction if that person wants to avoid that discussion.

To ignore that is to straight up deny what can only be described as flamebait.

It is not flamebait to say 'I think so-and-so handled a difficult problem well', especially as part of larger point. It's flamy to respond 'u wat m8?'. It's not a complicated thing and there's no 'fairness' in treating these things as the same.

>This is a particularly ill-chosen thread to deliberately try to re-flame this flamewar

Apparently it's the right thread to be rude and to assign intentions to people you don't know though?

And all because they dared say their opinion on a subject you're sensitive about?

How about that: people can have any opinion they like on Python 3, including considering it a botched migration process and a ho-hum update. And it's totally legit for them to speak about that. And it's not your place to censor them, or act up any time they express their opinions.

You can either add your arguments, or skip reading their comments. How about that?

Opinions are fine. But "Did you forgot the /s tag?" is antagonistic. Please don't antagonize.

That's the very point of a bdfl : it assumes he knows better than others. Debating is for insight and cortesy, not mandatory.

> That's the very point of a bdfl : it assumes he knows better than others

I think it's not that he knows better, it's that there can be a single, coherent, consistent design consciousness.

A BFDL can create an effective process of evolution rather than some of the more egregious open-mob process failures that are prevalent in open source.

But the B is for Benevolent. When a huge part of the community is against, does that B still stands?

If both kids want to eat candy as dinner, is the father blocking that not benevolent because he's outnumbered?

There is a reason kids aren't allowed to legally decide for themselves until 18.

In Python land, there is this saying "we are all adults here".

Being an adult also means avoiding creating needless drama.

They are, but they're adults who work in completely different environments and thus have wildly divergent needs.

One contrast:

You have some people who in business and want to do keep an old code base working forever.

You have some people who have no business experience and have no idea what a bottom line is, but might need a feature for a critical open source project that many others will use.

Have you ever tried to debate on python-idea ?

In nearly all cases where parenting is present, children are inferior to their parents in both intelligence and judgement.

This analogy does not work in software.

Repeating sametmax above: "That's the very point of a bdfl : it assumes he knows better than others."

He gave them a fantastic language for free and shepherded it for years - how much more benevolent does he need to be?

For every minute that he holds the BDLF title.

Benevolent: "well meaning and kindly"

You can do something that people disagree with, even something that you think is the best for them, and still be benevolent.

B stands for benevolent even in that case. The target of that benevolence is the project. His call should be in the best interest of the project (benevolent), final (dictator), and (tongue in cheek) eternal (for life)

The D is for dictator. When a huge part of the community is against, the Dictator overrules.

This is what happens when the B and the D collide: you renounce to the FL.

If you are a good person.

I agree with the idea you should give power only to people that don't want it.

I think guido was the right person in power.

Every feature ends up being controversial. Every discussion ends up devolving, somewhere, with some group, into bikeshedding.

Ultimately, it's up to certain stakeholders to hear arguments and make calls.

There are always haters but I don't remember any previous PEP being quite as unpopular as this one.

He fought for it because he thought it was the right call. The role of a BDFL is to make those kinds of calls for the benefit of the language and community. It's really tough to fight the "tyranny of the majority" and go with what you think is right versus what everyone is screaming and yelling at you about.

If 'everyone' was outraged, it wouldn't have been controversial, right? I'd argue that one person against _everyone_ else isn't a controversy, but in any case at the end of the day the PEP was accepted in a democratic poll.

On a related note, we've always had the constant outrage, its the internet that allowed it to become more apparent.

In 2018, we can finally use our advances in data science and social network design to precisely target outrage and make it maximally engaging.

Not to dismiss your point, but outrage on the internet is like a car wreck, its terrible that it happened but everyone on the road still wants to check it out and put their 2 cents in.

Seems like this thread is a few steps away from outrage about outrage :)

lol, if my migraine was still raging on then it probably would have been because of me :P

What I think would fix this, is better developer metrics and statistics. If every post to the python-dev list was automatically tagged with some sort of metric for that persons contributions to the project, it would go a long way to identifying, and triaging, the most violent vitriol.

Something like code contributions, amount of churn, speed of implementation, level of correctness, etc. Trouble is, I don't really see any quick "just insert batteries" method of adding such metrics to an open-source programming community - perhaps someone knows of a great system of reports for measuring developer productivity through a repo or something? I guess it would also have to accommodate dev-ops and marketing efforts by developers, too. Hmm .. maybe this is a startup idea in the making ..

> this age of constant outrage

And entitlement.

Outrageous. I’m offended, because I see open source as a great force for change, and I find your remarks belittling.

Denizens... please. I was clearly facetious.

Too deadpan.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact