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 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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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'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.
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.
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.
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.
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.
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).
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.
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.
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:
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.
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.
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.
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.
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!
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.
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?
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.
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.
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.
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).
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.
> 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.
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 :-)
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.
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?
</Sarcasm>
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.
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.
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)
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).
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.
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.
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.
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
like:
line = f.readline()
while line:
... # process line
line = f.readline()
or like this:
while True:
line = f.readline()
if not line:
break
... # 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
> 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.
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))
> 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.
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'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 -> ...
}
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.
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.
> 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.
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.
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.
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.
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.
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:
> 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
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.
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
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
> "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.
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?
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.
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.
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.
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.
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.
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
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 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.
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.
> 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.
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'.
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.
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.
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."
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.
> 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.
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.
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.
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.
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?
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.
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.
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.
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
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?
> 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.
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.
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)
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.
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.
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 ..
I'm not at all optimistic about this. I understand Guido's motives and sympathise with him, but I'm afraid this will have a very detrimental effect on Python and how its development is managed.
He says: "... I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions." I can only imagine what might happen without a single decision-maker -- just think of all the vitriol that was thrown about the migration to Python 3. At best there will be endless discussions, often being decided in favour of whoever was the loudest and most aggressive on the mailing list; at worst, we might end up with multiple competing forks of Python specification and implementations...
I'm hoping that the PSF will be able to elect a single "product owner"; I don't expect them to have the same amount of influence and respect Guido had, but it would be a good start.
Unfortunately, electing a single product owner is now a decision the core devs will have to weigh in on - which means it wont happen. Design by committee is a terrible way to run Python
All this over a god damn bikeshed that no one will care one way or the other about 6 months after its implemented. He didn't loose faith after the 2->3 transitioner but but a goddamn assignment operator that works just like so many other languages.
I mean it was bound to happen at some point, but I am really disheartened that it happened in this way.
Python's original "sales pitch" was that it was a clean and simple language. As years go by and more weird stuff is piled in, it becomes less Pythonic.
I forget which book this was from, but when I was learning python back in 2003 a major selling point was 'you can't make assignments in control structures'. Happy days to a physics undergrad who had seen more if(a=3) in C code than he could shake a stick at.
Sometimes less is more. Python is turning into more is less. It doesn't need to be everything to everyone.
Whenever they say that they either mean they only have 2G connection or they somehow managed to get a Gbit satellite phone so they could be online several hours a day from the woods
Not me. When I say that, I really mean it! I don't even have cellular service at home and internet is coming from a 2-man WISP capped at 5mbps. Makes for a fun conversation when a user says the app is "slow" to load...it loads faster than HN at my house ;).
It depends. My experience has been that contractors usually don't mind working on vacation while on a cruise whereas salaried people are like "I'm dead; don't reach me."
I think it depends on the type of person and on the type of job. As an independent contractor, you're more likely to have to at least be reachable while on vacation, due to the nature of the work, whereas a company with full-time employees is likely in a better position to have people go off the grid for a bit. That said, personally, even as a former contractor, I want NOTHING to do with work while I'm on vacation—to me, that's the entire point.
That is a really interesting point. Without some process formalizing his (desired it appears) removal as BDFL he could override any future construct that is built to guide python. The thought of a schism in the direction of python is worrying.
Edited to remove inadvertent backhanded compliment
At the end of the day, he's not actually a dictator. He's just a contributor with a lot of influence, borne out of respect, and that will remain true regardless of any formal or informal position.
Exactly, and if the community as a whole disagreed with him there is nothing stopping them from forking and forming their own org. Nothing except hard work that is...
For what it's worth, the variant of syntax Guido pushed is a really good choice and the fact that the mailing list "widely opposed" it only tells of the participants.
Now this is a very dangerous situation, looking how perl5 was handled after Larry wall left them and stepped over to perl6.
Constant infighting of the core devs, useless communication on the mailing list, not a single worthwhile feature being implemented in 15 years, even if perl6 and Larry designed tons of them suitable for perl5, total destruction of the syntax and the core. The better counterexample was perl6 with stricter processes and some capable devs remaining, but still it's another minefield.
Good luck, tons of work to do. python 3 could get 10x faster and catch up to php7 or javascript, types could get properly integrated but I don't see it coming. Usually you have to expect the worst.
I think had it been a more clear demarcation, like this, Perl 5 would be in much better shape today. Perl 5 has been doing well for a few years now, but it took a while for the Perl 5 developer community to fill the void left by Larry; there just wasn't an acknowledgment that there was a void to fill. Larry didn't die, still kinda paid attention to Perl 5 for a while, but his heart wasn't in it and his attention eventually shifted fully to Perl 6.
Now, the Perl Pumpking (a sort of Benevolent Punching Bag for the Next Release; they do have the ability to decide which patches go in, but usually don't wield it like a dictator) along with the dev community, does their thing...the pumpkin gets passed along every year or three, and things continue. And, Perl 5 is developing nicely in a way that it didn't for about a decade while there was so much uncertainty. The Pumpking existed before Larry left Perl 5, but acted more in a support role (as I understand it), so it seems like it took a while for it to become an acknowledged executive position when Larry faded from view in Perl 5 development.
I think Guido is doing the best thing for Python. If his heart isn't in it, stepping back in a clear way is much more helpful that drifting away and leaving a void of leadership with no one feeling empowered to step up. There are people who are recognized as being contenders for the throne, and there's already a long-standing community process. I think Python will be fine.
Regarding the endless mailinglist thread problem on this PEP, I can only recommend to use a different PEP tool.
A wiki leads to more structured argumentation, can be re-ordered and edited and doesn't get out of control. Sometimes I also use github issues, because I can update the issues there. But on big issues a wiki page is better.
Such a mailinglist discussion is mostly drama without much content.
Can tell you performance has never been an issue for me and python. Usually when I see the claim come up it is usually a poor test (ie "let's see how fast we can read from a database") or not knowing the performance options available to python. You can use pypy for JIT compilation performance. You can use eventlet to add co-operative threading / evented processing. Use multiprocessing if you want to use more than one core. The point of python is to optimize for human understanding 1st, and if your abstractions are good then you can enable extra performance with other libraries.
Python is the language I chose to teach my 7 yr old daughter. Much thanks to the uncluttered syntax which requires a minimum number of explanations of non-essential parts of a program.
As someone who used Python for more than a decade, a few months ago when I saw PEP 572 and that Guido liked it I knew that it would be by far the most controversial one ever.
And I was very concerned that there was no outside community involvement. This is one where there should have been a lot of publicity around, and the community should have been asked (on r/python, r/programming, HN, ...)
It's sad to see this, but it's not surprising to me. In general the Python community at large accepted Guido's decisions, but this one was too much of a shock, and when the python-dev discussions where so heated, you can only imagine the response from outside.
I honestly don't understand why it's so contentious, despite reading the lwn.net article about it[1]. It just looks like some syntactic sugar to me, and I've been in the position where not having that sugar has felt awkward many times writing python.
This is sad to see, but necessary at some point, as others have said. We should all thank him for his contributions, and for the advances in data science experiments enabled by Python's ease of use, good design, and advanced features.
I am glad that Python is recognized as the quality language it is.
Yikes. Python has become so hugely popular and is used for so many different use cases that I fear the ecosystem is going to really struggle to find consistency and direction without a dictator.
Maybe we'll try something like a triumvirate? As best I can tell there are basically three areas where Python is dominant: web, data science, and academia. A single leader for each of those spheres could form a council where BDFL-level decisions could be made by fiat.
Each community could then form whatever organization they felt necessary to choose who to send to the triumvirate.
As as check on the power of the triumvirate, we could have something like a "Tribune of the Plebs" - a representative elected by open election from the entire community that holds veto authority over changes approved by the triumvirate.
you're missing a body that can decide in case of implementation disputes over the other two. we could even compare it to a court. since python is so huge, we would have several levels for triaging and appeals. and the top one would reign supreme.
This would be the that body - it would be the final arbiter of what gets approved. The Tribune of the Plebs would not be able to approve anything at all, but would be able to unilaterally refuse to allow changes to be made.
The UN Security Council is somewhat similar in that respect, though comprised of more members. New matters are approved by majority vote, but the five permanent members can veto anything that gets approved.
My proposal is somewhat tongue in cheek, hence the names from the Roman Republic - but I do think the idea is sound.
An alternate, simpler implementation would be to simply require that all changes be unanimous. I like the idea of a Tribune of the Plebs though because it gives a second means of a voice should a sizable minority of members of the sub-communities strongly disagree with the direction of their representatives.
Django went through this years ago; Jacob and Adrian, who were the "BDFLs" of the project at the start, stepped down.
The current governance model is mostly around consensus on the dev list. There's a "technical board" elected every release cycle from among the committers, to act as a tie-breaker when needed, and with veto power over DEPs (Django's equivalent of PEPs) and adding new committers. I don't know of a case where that veto power has ever been exercised, FWIW.
It seems like Apple has lost the plot again, since Jobs' departure. Competent management but lacking vision. So, sure, it'll keep going forever, because that much capital can last and grow forever when competently managed. But, will Apple ever have another iPhone/iMac/iPod/etc. (the kind of product that shifts the entire industry in a notable way for the next 5-10 years)?
I could be wrong, and I don't follow Apple closely, but the impression I get from longtime Apple fans is that the last few years have been a stream of mild disappointments.
Reading that thread is like reading an actual Monty Python plot.
Guido van Rossum has given his life for this language and besides the obligatory 'thanks for all the fish' there isn't even a single person who stops the clock to evaluate what went wrong that they pushed out the person that started this all.
Instead it's 'kthxbye' and they're already dividing up the cake to see who gets to rule.
Not the nicest moment in the history of FOSS, I wonder what kind of a mess will ensue when Linus steps down.
We are acutely aware of why Guido is retiring sooner than any of us expected; it has actually been discussed already on the mailing list as to what went wrong with the PEP 572 discussion and how we could potentially fix it. So there's no lack of understanding of why this is occurring now and we have already begun to think about how to address the issue.
Many of us have also been thinking about what we would do when this day arrived for years (Guido has hinted at retiring previously), so there's a lot of pent-up thought to get out there while we all start to think about what comes next to a project some of us have dedicated decades to. The conversation has been thoughtful and not a single person has said "I should be the next BDFL". All names put forward by anyone for any position has been by another.
IOW the insinuation that any of us who are trying to grapple with this are trying to vie for power while ignoring why this occurred does not seem like a fair assessment to me. This kind of unnecessary negativity and accusation is why Guido is retiring early.
What are they supposed to do? Python is bigger than GvR. A pretty big chunk of the tech industry depends on it. We were probably long past the point where a "BDFL" was healthy --- not because of any moral issue, but because over the long term the market is going to dictate where Python goes and how it grows, and people should stop kidding themselves that it might be otherwise.
I don't think it's at all unseemly that people involved in the Python project respond to GvR's LOA announcement by working out continuity. As someone who has to interact with a lot of Python code professionally, that's exactly the response I'd hope for.
> but because over the long term the market is going to dictate where Python goes and how it grows
The market gave us the absolute mess that is HTML/CSS/Javascript today, so I'm sincerely hoping the Python community will keep agreeing on some greater design principles instead of leaving everything to market forces and pragmatism.
"The market" took over after a long period of "design by committee" that had "strong design principles"[1] resulting in something that was both inadequate for what people wanted to do and didn't evolve at a promising pace (likely because of said principles).
When the market did take over, the problem was that those poor foundations weren't thrown out completely. You can only do so much by strapping turbines on a camel (no offense to camels). At least we can actually write (mediocre) applications with HTML/CSS/JS now.
The other part of the mess is caused by the ever-growing amount of trend-hopping junior developers
that want to try out new things - and their superiors letting them do it. If the foundation wasn't so bad, there would be less incentive to try and re-invent anything. Other platforms are fully market-driven, they didn't produce such a mess, because the market rewards stability (hence the low initial adoption rates of Python 3).
> "The market" took over after a long period of "design by committee" that had "strong design principles"[1]
Yes, but a committee (or a community if that term has too many bad connotations) can at least argue about the design principles and on occasion decide to change them using a well-defined process (e.g. rough consensus or voting).
> When the market did take over, the problem was that those poor foundations weren't thrown out completely.
The original plan of the W3C TAG was to pull the foundations and make a fresh start with XHTML2. The browser vendors objected to that and chose to instead evolve the original HTML into what we have today.
> The other part of the mess is caused by the ever-growing amount of trend-hopping junior developers that want to try out new things...
But that's the point. Those trend-hopping junior developers and their bosses are the market: If you view programming languages as products, those are the early-adopters, one of the generally most sought-after part of the customer base. If you want to be 100% market-driven, you have to listen to them.
> ...because the market rewards stability
The market apparently didn't bother much that HTML is now a "living standard", browser release cycles are measured in weeks and generally a software is considered dead if it doesn't receive any more updates.
> Yes, but a committee (or a community if that term has too many bad connotations) can at least argue about the design principles and on occasion decide to change them using a well-defined process (e.g. rough consensus or voting).
The underlying assumption here must be that this somehow leads to better results overall, but where's the evidence for that? "Design by committee" has a negative connotation for a reason.
> The original plan of the W3C TAG was to pull the foundations and make a fresh start with XHTML2. The browser vendors objected to that and chose to instead evolve the original HTML into what we have today.
That's because "the market" doesn't want things to break. Like I said, it should've been thrown out, but for obvious reasons it wasn't. The point is, you can't blame "the market" for having created the mess in the first place.
> But that's the point. Those trend-hopping junior developers and their bosses are the market...
They are a force within that market and it just so happens that so many new people come into the industry because "web stuff" is needed now, but it won't be growing like that forever. These young programmers will grow old and tired (and so will their bosses) and at that point conservatism will settle in, like it has in many other areas as well. It's a market fluctuation.
> The market apparently didn't bother much that HTML is now a "living standard", browser release cycles are measured in weeks and generally a software is considered dead if it doesn't receive any more updates.
The pace at which new browser features are adopted is actually rather slow, but more importantly, old stuff usually doesn't break. For example, jQuery might be outdated from a developer perspective, but it still powers a lot of stuff.
So the reality is that the growth of the web far outpaced any sort of design principles that could have been implemented by any committee.
TCP/IP development happened quietly for the most part in the 1960s-70s. There wasn't a lot of pressure, and they had a decent amount of time to get the protocols right. There wasn't an economic demand for Arpanet.
And it wasn't until about 1993/1994 that the web exploded in use and popularity. That was only 4 years after TBL created HTML. That's when you saw the explosion of JS/Java Applets/CSS/Browser Plugins/etc.
In some sense, the same thing is happening in the python world. While python has been around for a while, there were maybe 800 python devs at Pycon 2010. In Pycon 2018 there were 3000ish(?).
I do agree with you that the Python 3 update wasn't done well, I think it is because they didn't predict the language's explosion during the 2010's.
I think Javascript has been rapidly getting better, as a language. Every time you hear a front end dev complain about having to support IE, consider that an endorsement of the way HTML/CSS/Javascript has been improving. No one is complaining about having to use the latest version of Javascript to support the new Chrome.
Dunno about that. According to Kyle Simpson (https://www.youtube.com/watch?v=2pL28CcEijU) ES6 has introduced plenty of WTFs to add to the archives. Back-to-front, inconsistent destructuring and Symbols which hide from object enumeration. And after all these new versions Javascript still lacks really basic functions such as range().
Oh I hope not; I much prefer the much more regular release schedule of Python (though since I went from C++ to Python a few years ago, I understand C++'s development speed has picked up somewhat).
New versions of C++ are released every 3 years, very systematically. It's much more regular than Python. Did you mean "frequent"? Python's sporadic releases are a bit more frequent.
Some root cause analysis would be nice. Because whatever went wrong that caused GvR to step down isn't solved and the future structure whatever form it will take will most likely not be quite as resilient against this as GvR was.
Also, an apology for the way this turned out would be seemly.
Whatever apology GvR is owed, it's none of my business. The post-BDFL continuity plan is super relevant to me, but I can say with some confidence that GvR does not need me as a witness to whatever psychological remediation he may or may not need for the assignment expression debacle. It's not my place to psychoanalyze him, and he rather clearly didn't ask me to.
So again: why, as a professional who interacts with the Python ecosystem, am I interested in anything more than what is already happening on the thread?
Are you not interested in what caused the leader of a community to step down? Do you not think that that information would be helpful in sustaining the community? This event is not business as usual, it should be considered with great care.
Not really? I'm not suggesting that great care shouldn't be taken; I'm suggesting that there's no evidence that it hasn't, and that neither you nor me are particularly important players in the story of what is happening, and that nobody owes us an explanation. Certainly, a concerted effort to prevent GvR from stepping down as BDFL seems silly.
I'm not implying an effort to prevent GvR from stepping down, but I don't think the lack of public consideration among core devs on why this happened is healthy either.
I don't see it as mystery as why it happened. Perhaps you are thinking there was some specific trigger for his stepping down. I don't think so. When the language becomes as popular as Python has, the head of the project is going to become a target for a lot of unwanted attention. The "assignment expression" PEP was a good example of that but not the sole cause.
Even if infuriating jerks are 0.1% of the population, when your language has hundreds of thousands of users, you are going to deal with a lot of jerks.
Frankly, I'm surprised he lasted as long as he did without going mad or something. I would not wish for any of my friends to be subjected to that kind of attention.
We were very lucky to have him leading the project for so long. Python will survive without a BDFL and I hope he enjoys the vacation.
I'm not exactly implying that it's a mystery. Mystery or not it I think it warrants some public consideration. If the reason indeed was 0.1% jerks, that should be confirmed and addressed in writing.
If a parent tells their 25 year old child that they’re done with it and sick and tired of the job, I think the child should at least look inside themselves and assess whether anything they did that prompted that should be changed.
If the relationship between GvR and the Python project was some completely different relationship (parent-child, facehugger-host, butterfly-cyclone, etc) then maybe there should be some completely different response. But it's not.
> I'm not suggesting that great care shouldn't be taken; I'm suggesting that there's no evidence that it hasn't, and that neither you nor me are particularly important players in the story of what is happening, and that nobody owes us an explanation.
Completely tangential, but the density of negatives in that sentence was nothing short of majestic.
Why you should care: it's relevant to the post-BDFL continuity plan, because 1) the stressors that pushed GvR out will also act upon the new decisionmakers, 2) those stressors can be reduced, and 3) change-of-control is innately risky and we should be extra-worried (at this moment) about existing, important stressors.
I care that those concerns are being addressed. I do not care whether they're addressed in public in a way designed to mollify any particularized concerns I might have, because I am not a member of the Python core team, and they don't owe me that.
I mean, nobody on the py-committers threads owes you anything. But OP was observing an apparent gap in their thinking -- and indirectly, stating there is a toxic element of culture that destroys leadership morale, which nobody is (publicly) commenting on.
I think you'd say the same, if you agreed that culture was a solvable contributor to GvR's exit (even if you, like me, knew he was leaving for market reasons eventually). By analogy, if 'dang said "I'm leaving yall, this sucks, elect a replacement" and we were like "cool who's it gonna be". That would be an error, and I think you would be at the top of the comment page saying "Also, let's all make some changes so that the next 'dang doesn't have a miserable life."
Why do you think something went wrong? He is upset, but the root cause analysis is very simple. It's "GvR is upset <- Python has politics <- Python is large".
A huge thank you is more than deserved, but not an apology. Nobody did anything wrong, GvR's position just stopped being fun because he was too successful.
I imagine they already have opinions about what caused him to step down and either don't consider it a real problem for whomever or whatever succeeds him or at least think it best addressed by that person or people. In other words, figure out the leadership structure and let them deal with it.
Isn’t this what always happens though? A remarkle person or small group of people creates something unique and of value. As this thing is adopted by more and more common, unremarkable folk (like me) a market and great demand is created and power over the thing and its creators is established. This power voices opinions and suggestions which in aggregate are a reflection of all the commoditised stuff that already exists. The thing evolves to follow the demands of the market power. The thing is no longer remarkable, its creators move on to the next thing.
You repeat that "The thing evolves to follow the demands of the market power" but that doesn't make it true. You can probably think of counterexamples, likely a dozen off of the top of your head.
I got the impression that this was mostly just a public announcement of something that has been talked about in private for quite some time, and was not in the least unexpected to the core devs. If this is the case then the reaction is suiting imho - after all, these people know each other very well and even if they didn't talk about it openly, they probably weren't surprised to receive the mail. Besides - it would have happened sooner or later. As he said himself, that bus is still lurking around the corner... [0]
I do hope he knows how his contribution changed the world for better for so many people. I have played around with many languages in my career but Python is the most productive and fun of them all. Thank you GvR, and may you have fun whatever you do!
I don't think a public thread is the right time or place for such a retrospective. Keep in mind Guido's parting words ("Finally. A reminder that the archives of this list are public").
And I'm not sure who would be the right person or people to apologise. A number expressed regret at what happened, but I don't really think the core devs are at fault here.
On the subject of Linus, I wonder if he feels the same way about kernel discussions or if he is less at risk of this kind of burnout?
Does being more empathetic when dealing with contributors and their suggestions extract a greater price on one's emotional state, compared to the more brash approach Linus has?
You nail it, I think. Being nice to contributors leads to bullying. Contributors assume, then feel entitled, and it gets harder and harder to say 'no' -- and it's probably very taxing.
Linus shoots first, that keeps the bullying down -- of course everyone else thinks he is the bully, however he's just protecting himself. I've spent many years victim of bullying, and I know that the only way to beat a bully is to out-bully him.
I think Linus's main point is that if he seems happy about something he's actually uncomfortable with, developers can sink a lot of work into something he ultimately doesn't like and doesn't want in the kernel. So the aggressive approach is to stave off that outcome, which is fair. I suspect he also enjoys it - which is also fair enough.
I think with Linus' "my way or the highway", at least some of it comes from early upbringing. His dad ran for president (unsuccessfully) in Finland recently - intelligent, likeable but very opionated guy.
There's certainly a friendly nod to the CoC and an invitation for people not willing to adhere to it to leave —and I think that alone would help chill things out— but it's a sustained level of often-thankless hard work. Especially if you have a day job where they're pushing for more and more performance.
This missive is about helping the project move on, not himself. Bollocking the people who have made things hard isn't a productive next step. It's not what's required now; the core devs need to work out how decisions are made.
...there isn't even a single person who stops the clock to evaluate what went wrong...
This is perfectly consistent with 99% of the management behavior I've witnessed for years in the enterprise. We understand that we live in a world of cause and effect, but almost everyone is so busy poking at the effect that there's no energy left to discover and treat the cause.
It's a shame that so many of us workers continue to have so much passion for the work at hand and so little for everything else. It seems like it almost always comes down to this.
That seems too easy. That guy was the core of the Python community for over 20 years. Supposedly he has seen a lot of ups, downs and drama and experienced the downward slope of the motivation curve often enough and still held on - until now. So what was different this time?
> There is no real cause to "treat", you just need to adapt to the new environment you are facing.
Maybe, maybe not. The purpose of a deeper analysis should be to find out whether or not it might be like this - but you can't just assume it's like this from the start.
> That guy was the core of the Python community for over 20 years
Exactly. I can't imagine keeping the same job/role for 20 years. Guido even says it : he is tired. He has had the energy, drive and will to steer the python ship for 20 years. He now feels that it is time for him to take a well deserved holiday/vactaion/time off.
As other have said, this has probably already been discussed within the core devs already.
But people need to find a "reason" to explain what is just a very natural process. And will spend countless hours looking for it instead for just moving to the next adventure.
> there isn't even a single person who stops the clock to evaluate what went wrong that they pushed out the person that started this all.
True, although sometimes there isn't much to be done. He mentions he is tired of fighting and, with such an enormous project, how do you solve that?
This does not bode well for the future of Python, though. The ecosystem is fragmented as it is, I can only imagine how things will look like without the well known leader.
> Guido van Rossum has given his life for this language and besides the obligatory 'thanks for all the fish' there isn't even a single person who stops the clock to evaluate what went wrong that they pushed out the person that started this all.
The lack of introspection that causes one to, in the heat of the moment, behave like a tedious buffoon on a public mailing list is probably associated with the lack of introspection that causes one to not reflect on having behaved like a tedious buffoon on a public mailing list.
On the other hand, I had never looked at the Python mailing lists until today and my main impression was that a real dictator on a mailing list without a Code of Conduct could have stopped some of that endless chatter in its tracks if he'd really wanted to. Absolutely no one springs to mind...
> Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.
Inflammatory generalizations with no evidence like this count as flamebait, so please eschew them.
You're making an astoundingly general claim and chimpanzees are not going to back it up. I understand that you might disagree, but there are community standards of discourse here that are not being met and we need you to work on that if you're going to comment.
I didn't have time to dig up more studies but I certainly could if I was paid to. My claim is true and all research on this topic has overwhelmingly confirmed my claim on male group behavior in apes, humans included.
In any case I've acted in good faith to contribute positively to the discourse. I haven't antagonized anyone and I've provided relevant new information that might shine new light on the discussion at hand. If anyone isn't meeting the standards of civil discourse, it's you and whoever flagged my comment. You'd think people on HN would be curious about new ideas. Instead all potential positive discourse is shut down due to a single individual's subjective judgment of what is inflammatory, despite it being scientific consensus. It's clear this isn't a space for civil discourse amongst reasonable people.
The problem is that they aren't new ideas in the sense that matters here. They fall into very well-grooved grooves and we know from experience where those lead. It isn't groovy.
When we moderate HN like this, we don't mean to imply that you weren't posting in good faith. We're just being vigilant about what is known to cause flamewars. Flamewars are the #1 problem here because they consume everything they touch and can easily lead to the death-by-fire of the forum. We're basically just being Smokey Bear, or Smoky Bear's ranger friend.
It's interesting to observe that the above holds true even if you're right in everything you said. The old question "would you rather be right or alive?" applies here.
What would be new in the sense that matters? I think it was a natural flow of discussion: someone gives their perspective on an event, another person shares a related scientific fact that supports that perspective. You aren't being clear, instead you are throwing out abstract words like flamewar, flamebait, groovy, etc. I'm not getting the memo. Please be specific, what exactly was wrong with that post? Do you have a standardized list of topics that you guys censor for fear of flamewars? Can you share that list with the community? If not, this seems arbitrary, illiberal, anti-intellectual, dictatorial.
Sorry, but this is the classic legalistic gambit of the troll.
It's not hard to figure out the intended use of the site. If you don't want to use it that way, please don't post here and please don't make new accounts to get around the restrictions.
I was moderator for more than 10 years on linux.org.ua and nobody told me that I was bad moderator. I also regular user on other forums/sites, so I have view on the problem from both sides.
HN is badly moderated. However, most problems with moderation/flames/etc., can be fixed using technology or by writing better rules. If you are interesting in fixing of HN problems, contact me: vlisivka@gmail.com .
Happy to listen to user opinions and do so every day, but when someone has a history of not following the site rules, as you do, their complaints become less compelling. This can be fixed by reading https://news.ycombinator.com/newsguidelines.html and taking the spirit of this site to heart, and using at as intended from now on.
Well, I agree that I'm not the best HN user, but I'm not a young inexperienced person: I survived few assassinations, and lost few friends, which were not so lucky. I also quite busy with my work, my startup, education, science, history, politics, and some other topic, so I will not post something just to insult somebody.
IMHO, HN can be improved to automatically filter out discussions. Imagine, we have a magic system, which automagically labeled all comments as a) on topic or not on topic b) improvement, critics, opinion, correction, controversy, alternative view, support, trolling, joke, fun, suggestion, discussion, flame, etc. c) history, politics, physics, mathematics, engineering, computer science, programming, etc. Then we can just place some labels on top of each submission with number of comments for that label. By default, only on-topic comments with good labels should be enabled. But user should be free to enable other topics as well.
Now, we need to imagine how to implement such automagic labeling system with minimum of up-keeping cost. IMHO, first we should allow user to label his comments himself. If comment is labeled properly, then user will not punished. If comment labeled incorrectly, then other users can vote to change label with cumulative score (if user has higher rating, his vote worth more), and user will be automatically punished if label changed from good to bad.
On-topic/off-topic should be implemented as checkbox on submit form. Other labels can be implemented as hashtags or collapsible boxes. Users should be able to add or remove labels to other posts, if necessary, when they have high enough rating for such action and label. Users should be able to chose which labels they want or don't want to see with reasonable defaults.
IMHO, it's much better to be constructive ans ask user to label his post as "#politics #flame" instead of forbidding him to post.
Example:
A post title.
yyyy.mm.dd hh:mm
on-topic(12) off-topic(21)
vlisivka x hours ago | off-topic(up dn)
#hn-site #suggestion (add label)
I have a suggestion about how to improve HN.
> Lower ranking males tend to act in ways that subvert higher ranking males
Just want to say: It has nothing to do with sex - women do this also. Please refrain from characterising whats going on with Python right now as being a consequence of some sort of masculinity out of control, because I fear that is a falsehood and does you - and anyone who tries to agree with you - a major disservice.
That was nicely said. The statement is factually accurate but is the corollary of how to lie with statistics (how to lie through omission by characterizing group X as possessing property Y when it is also possessed by X complement).
There is no wrongdoing mathematically, but it does show that selective vision is a force for damage if wielded improperly or with agenda.
Thanks harlanji, hopefully dang or sctb unflags my comment. I'm not sure how I broke the rules with that one, outside of it apparently being unpopular. Very strange.
It takes someone dedicated to do what you have done for this long. You need the vacation more than anyone else. I wish you had a tip bucket somewhere and I’ll gladly donate for some of your vacation cost, simply a thank you tip for your tireless effort.
Thanks Guido. Python was my primary language from around 2004 - 2017. I've had the chance to present at Pycon a couple of times and get my feet wet in contributing to open source projects with Python. Best of luck.
Thank you Guido for creating and shepherding such an amazing language one that has been my go to language for years for its ecosystem and it’s beauty. Seriously thank you so much.
To Guido, a career's worth of thanks (I doubt I would have had one without Python) and for being encouraging and supportive to a very young dev at a long ago conference - to keep that up over decades means encouragement, mentoring and optimism was bred in your bones. Have a lovely permanent vacation.
To the python community, I hope we can find a successful, democratic way forward.
To myself, public service is a good thing - try harder !
"bus lurking around the corner" caused me a Family Guy style flashback.
"Like that time [victim of an unsolved bus stop stabbing] was killed by a bus." victim sitting alone at a bus stop. glint of light from the dark alley in back. bus jumps out, stabs victim. bus enters street, transforms into normal bus, drives off.
Guido, thanks for all your work on Python. It made a huge impact on my life. I have been writing python for the last 12 years and enjoyed every moment. For many years Python was the best way for me to translate my ideas into a working program, and it made a major effect on the way I think. I wish you great luck on all your future endeavors!
Related: Brett Cannon's Keynote at PyCon 2018 about why he had to take a break from Python core development. I was sitting with him before the talk, and it was a really, really hard talk for him to give, emotionally.
Am I mistaken for not considering this PEP (and all PEPs in general) as strongly backed by Guido? I always assumed they were sort of design-by-committee and that he approved of some more than others. Offline, in private, I've been pretty critical of the change, but to me it was just another PEP.
Python is certainly one of the more opinionated languages in the OSS world, so there was always going to be contention on syntax and what it means to be Pythonic etc. Kinda amazing Guido put up with it for this long.
Thank you, Guido, for putting the B in BDFL when you could.
Naturally people went to the barricades for it, in a classic example of bikeshedding and Wadler's Law (programmers will fight to the death over trivial syntax disagreements and just shrug at profound changes to semantics and architecture)
That's not an accurate summary of assignment expressions.
Assignment expressions perform the assignment and also return the value of the assignment. So you can assign and test a conditional at the same time. It's quite an elegant alternative to some quite verbose repetitive code you would otherwise have to write in some scenarios.
Assignment expressions are also found in languages like C#, and have proven to be of great practical value.
f-strings was another Python 3 idea that was pre-dated by an implementation in C# [1] ($-interpolation) and it was a popular idea in that language too.
I don't want to proffer an opinion on PEP 572 since I haven't followed the discussions, but these things have been "bench-tested" in other languages and not been found wanting, so I do wonder a little bit about the true cause of the controversy.
Yes, I don't really understand the controversy either. I work with Python a lot in my day job, and I am quite frustrated with how slowly the language moves. For a long time, it seemed like the reason was the Python 2-3 switch, but now we don't have that excuse, and things are still slow. Every little decision seems to get immobilised at the PEP stage.
I'm sorry, I should have clarified. There was a lot more to the PEP than what I mentioned, it just seemed to me like the loudest and dumbest arguments against it were complaining about the colon and not anything substantive.
That's pretty much the main use of the new syntax. When you have a cascade of regexes, it is even better:
if m := re.match(...):
...
elif m := re.match(...):
...
The world is not coming to an end, as some detractors of the PEP might think. The new syntax is a win in a number of cases. Otherwise, you don't need to use it. The concern for abuse is way overblown. I could live without it (voted -1 on the idea originally) but now that it is in, think it is fine.
Yep, and common for regular expressions. I’d alwayed liked the simplicity of Perl’s “if ($x =~ /.../) {“ and in Python you had to create the match object before you could test it. Assignment expressions should work nicely there.
Guido's question gets to the heart of the problem:
"So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?"
No. None of the above. These are mechanisms which make choices when a choice must be made, even if none of the options is broadly acceptable. An appropriate mechanism for, say, governing a country.
Python isn't a country, it's just a programming language, so when there aren't any popular options _doing nothing_ is always the backstop. Does that mean that maybe, eventually, your programming language will shrivel away and become irrelevant? Yeah, it does. But again, not a country, just a programming language, use a different one.
Rough consensus is what you need here. PEP 572 never had rough consensus. Could it have obtained such consensus, someday, perhaps, with more work? Maybe, though I doubt it. But it didn't have that when the PEP was rammed through by the Benevolent Dictator.
Consensus approaches are terrible ways to design languages. It's why Java took so long to evolve, where C# rapidly adapted to changing needs; and why C++ lingered in a long state of crappiness until Stroustroup came back and is now pushing improvements every three years.
Languages generally do well when there is a sense of leadership and vision for where it is going. Consensus is terrible at providing both.
Who decides when there's rough consensus or broad acceptance for a change? You have a bunch of people with commit access to the python repository; of course you need some mechanism to decide what goes in.
A rough consensus is trivially observable. Look around. Who's left saying that plan Foo is a bad idea? Just that one guy who is a total crank and thinks Python shouldn't support 64-bit processors? Nobody cares about him. How about people who think plan Foo is a good idea? Basically everybody who talked about it other than the crank: OK, that's rough consensus.
If you have situations where your "bunch of people with commit access" aren't sure if there's consensus then you don't have a consensus.
As to why you need it: Because unlike countries people have a real choice. All your language users are volunteers. (No "Seasteading" and "Freemen on the land" are not real choices). Not only can they freely choose another language instead of Python, they can fork Python and go make their own instead, or maintain the current code frozen in perpetuity.
Now, if there really is a 50:50 split between people who must have feature X and people who'll leave if feature X is added to Python, nothing you can do will solve that. So it's wrong to try to design your structures for that problem. More often there is a third way, and consensus helps you to be sure you found the third way.
What if the core committers are generally decided for A but the language users at large are for B? The way you make those decisions is a mechanism, even if you don't want to name it.
In the scenario you describe there sounds like no consensus for A or B.
Maybe, after they explain how great A is the core committers can bring the language users around on the idea of doing A. Maybe after spending more time considering why B is beloved of language users the core committers come around to B.
Perhaps most likely if the two conflict is that C is developed as both sides look for the best of both, what an excellent outcome.
And if not, then do neither A nor B
We regret our bad ideas at leisure. No need to bake those bad ideas into a programming language just because of a vague feeling that "we must do something" (and as the saying goes "this is something, so we must do this").
I don't know if it's just me, but if you read the forums and bug reports related to open source projects, it feels like programmers today are a really entitled lot.
The tone that people take when filing bug reports for what is basically free software is reprehensible. People are doing work for FREE to benefit you, and you take a tone with them like you are a prince and they are your royal goblet holders? Who taught these human beings their manners?
I totally understand the frustration when you write a large system in Python and then the Python committee makes a breaking change that makes your life very difficult. However, you didn't pay for Python! These sorts of changes should be expected, and if you didn't expect it, you are the fool. And in any case, you aren't paying these people a cent, so speak politely to them. You are basically a charity case from their perspective.
One person who understands and writes extremely well about this dynamic is Eliezer Yudkowsky. From the incomparable Harry potter and the Methods of Rationality: [0]
""I was going to be a hero, once," said Professor Quirrell, still looking upward. "Can you believe that, Miss Granger?"
"No."
"Thank you again, Miss Granger. It is true nonetheless... I was not naive, Miss Granger, I did not expect the power-holders to align themselves with me so quickly - not without something in it for themselves. But their power, too, was threatened; and so I was shocked how they seemed content to step back, and leave to that man all burdens of responsibility. They sneered at his performance, remarking among themselves how they would do better in his place, though they did not condescend to step forward...Perhaps, by taking on himself the curse of action, that man removed it from all others?...
"So -" Hermione's voice sounded strange in the night. "You left your friends behind where they'd be safe, and tried to attack the Dark Wizard all by yourself?"
"Why, no," said Professor Quirrell. "I stopped trying to be a hero, and went off to do something else I found more pleasant.""
This might be hard to grok without reading the preceding 83 chapters but it is the first thing that came to mind when I see how people treat open source contributors.
I grok. I have neither read this, nor have I read any Harry Potter (much to the chagrin of many of my friends, I'm sorry, I've tried).
This sums up a fairly universal behavior that I think we all tend to take part in, and also see others taking part in when we all spot a problem but don't take action because we have the luxury (i.e. removed from any real chance of harm) to watch the problem be solved by anybody else. Then we use this position of luxurious inaction to judge and complain.
I'm surprised by the reactions I see here though. I'm not invested in the subject of this post, but I can see the hurt of this person in their post. It also appears that they are not bailing, but simply allowing others to try and do better, with suggestions to boot.
And here we sit, justifying our luxurious anger at a person so exhausted from doing free work that they have to walk away from what I assume is a passion of theirs.
IMO HPMOR is a rich reading experience with nothing besides familiarity with Harry Potter as a cultural phenomenon (i.e. you know that they are wizards and they go to wizard school). It really picks up about 60 chapters in though, and that's a lot to ask someone to get through.
It is worth mentioning that Eliezer Yudkowsky doesn't believe in the scientific method, and thinks it can be replaced with pure Bayesian reasoning, without, as far as I can tell, any data collection.
I'm not even sure I should bother replying to this. But, like many, I'd consider the scientific method properly applied to be a special case of probability theory, modulo some social rules that might technically depart from Bayesian reasoning but are supposedly there to create good equilibria among less than perfect reasoners. This involves observation, natch.
The parent commenter is presumably beyond all help, but anyone interested in an example of my views on this point may consult "A Bayesian view of scientific virtues" here: https://arbital.com/p/bayes_science_virtues/
I am amazed you took the time to reply to this as well, but, just so its on the record, having read more than a little of your material, I do consider your entire "rational" movement a bit of a cult.
The 'scientific method' is not something that can be reduced to formal reasoning. Bayesian inference is a type of formal reasoning for making predictions, and as such, is a mathematical 'toy model' that doesn't correspond to the real universe.
Yudkowsky worships pure mathematics, but he always had it 'arse backwards'. It's not pure mathematics that's the ideal, it's numerical and iterated methods and heuristics (cognition). Pure math can only be applied to idealized situations, whereas numerical methods and heuristics apply everywhere. So in fact, it's numerical methods that are fundamental, and pure math that's the imperfect idealization!
Yudkowsky read too much Tegmark in his youth and was sucked in by the idea that 'everything is mathematics' (or 'everything is information'). But to repeat, this is all 'arse backwards'. Thank goodness that I read some Sean Carroll and debated with a friend of Sean's on his forum; that's what finally talked me out of all that Tegmark multiverse/'reality is a simulation' nonsense.
It's the physical world that's fundamental, cognition is next level of abstraction up, and pure mathematics is a top-level abstraction (it's not fundamental). As Bayesian inference (and all formal methods) are part of the domain of pure math, they can't serve as a foundation for rationality.
Cognition is more fundamental than math (because it's closer to the base level of reality - physics).
As I commented recently to Scott Aaronson on his blog, what distinguishes cognition from pure math, is that pure math is about fixed equations, whereas cognition is about heuristics , iteration and numerical methods. But in fact, P≠NP implies that cognition is the more fundamental. See:
So for instance, AIXI (a much touted mathematical model of general intelligence), is the 'fake' (imperfect) solution, whereas a workable heuristic implementation would be the correct (perfect) one. This is the complete reverse of what Yudkowsky thinks.
I'd like to assure anyone reading this that the above commenter has no idea what Eliezer Yudkowsky thinks. I, with my considerably greater knowledge of that subject, can testify that among Yudkowsky's beliefs is "Bounded agents are more impressive than unbounded agents."
(In general, you would be very very wise not to believe someone who claims that I believe a thing, until you have seen the original text, in its original location, in full context, written by me under my own account, plainly and unambiguously saying that I believe that thing. Even then I've been known to change my mind later, as is a sane person's right. But most of what I'm wildly rumored to believe is more completely made up out of thin air than anything I've changed my mind about.)
I think what you're saying is true in the case of someone just throwing up some code they wrote online without any plan of supporting or developing it further.
But once you call it an open-source project, and you have docs and a roadmap and an issues page and stuff, you're making an implicit contract with people who use it that it will do a reasonable job of solving the problem it claims to solve. The user is choosing to use it over other alternatives and investing time learning and integrating it, so it doesn't seem at all unreasonable to me for them to be frustrated when they realize that due to some bug or limitation it doesn't actually solve the problem for them that it claims to.
As an analogy, if you give someone free food and it makes them sick, are they justified in getting mad at you? I think most people would say yes. IANAL but I'd imagine that if you got food poisoning from Ben & Jerry's free cone day due to negligent sanitation practices or something, you could probably sue the company just like if you had paid for it.
Or, if a member of some sort of volunteer community board is doing a bad job, people will complain about it. An open source maintainer is basically in the same position.
Of course, that's no excuse for being rude to them, but you also shouldn't be rude if you paid for something and it doesn't work. I'm not saying we shouldn't do anything to reduce hostility towards maintainers when it happens. But it's not true, in open source software or anywhere else, that just because something is free there are automatically no expectations around it.
I think theres absolutely zero implicit contract that implies that open source software maintainers owe ANYone ANYthing at ANYtime.
That's the reason it's open source because everyone can fix it, all an open source maintainer owes you is a P.R. review.
Therefore if an open source project maintainer is giving you their time and patience then you better be extra polite and grateful to them.
If Ben and Jerrys left a bunch of ice cream on the sidewalk and a bunch of people ate it and got sick then there would be zero liability on Ben and Jerrys.
> If Ben and Jerrys left a bunch of ice cream on the sidewalk and a bunch of people ate it and got sick then there would be zero liability on Ben and Jerrys.
Citation? That doesn't seem right, based on my anecdotal knowledge that restaurants take care to throw leftovers into a garbage bin rather than leave them out somewhere where someone could eat them and expose the business to liability.
I looked up this claim myself. In 1996, President Clinton signed the Good Samaritan Food Donation Act into law to limit liability for those who donate food. [1] The majority of restaurants still discard leftover food due to concerns over liability, though. [2] Clearly, liability was a real issue at some point in the past. I don't know enough about the current law to know how easy it is to take advantage of the new protections; I can understand why people are still concerned.
In summary, liability issues vary by country and are not clear-cut. As an analogy for this open-source situation, they don't clarify matters.
> based on my anecdotal knowledge that restaurants take care to throw leftovers into a garbage bin rather than leave them out somewhere where someone could eat them and expose the business to liability.
This is an outright lie. It has NEVER happened that a business has been sued for donating food. Not once. It's just a convenient excuse for saying '%$@# the poor.'
In your analogy you're citing a business. Then if you open source something you wrote, are you claiming you are a business? No matter how un/business-like the open source claim may be: has any money changed ownership between the parties in the course of the person writing and maintaining software vs the person using that software?
If no business transaction has been formalized then why should either party be liable? Indeed, if a person is not permitted to simply say "this is the software I am using" without also becoming liable for problems caused when other people use or look at that software? I don't think it is right to allow a person to be liable just for the speech of their software.
Fortunately, a lot of open source software is known to be open source because of a license file. Many open source licenses declare no liability or warranty of any kind. In that case, would not any liability claimed would be forfeit? Otherwise they would have been using the software in breach of its declared intended purpose at the point of time being talked about.
Every person has a duty of care to minimize the possibility of harm to others. In some professions the standard is higher and may be codified into statute and/or bylaws of their professional association e.g. medical and legal professions. What this means is that, for example, in certain jurisdictions a doctor is bound by his Hippocratic oath and has to render medical assistance to a person who is in urgent need of it, as quickly as practicable. Ignoring this exposes him to liability. So in the particular case of software, a malware author could in theory be found liable by posting his proof of concept in the public domain.
Secondly, in certain jurisdictions, there is an implied warranty of merchantability and also of fitness for a particular purpose. In the US this is under the Uniform Commercial Code.
Most (all?) open source licenses have a clause disclaiming any implied warranty or fitness for a purpose.
The example you cite of a doctor being required to provide emergency medical care I don’t think is quite accurate. In fact, doctors are often not covered by “Good Samaritan” laws and can be held liable if they do stop to help someone and something goes wrong. A layperson would not have that type of legal exposure. Medical treatment issues are complex and I can’t see how they are related to open source software.
That’s the point I was making: it’s not so cut-and-dry as the parent assumed. Depending on the jurisdiction, some actions (or inaction, as the case may be) have consequences. And not all disclaimers are lawful, especially with regards to disclaimers of warranty.
In the U.S., a doctor has no affirmative duty to provide medical assistance to injured persons if they have not established a special relationship with the individual.
> all an open source maintainer owes you is a P.R. review.
What? Given what you said in your first sentence, this seems a bit contradictory. When I post some code online, nothing forces me to review PRs other than an implicit social contract.
The likelihood of a rational person ignoring PRs/issues seems pretty low, since one typically wants improve their software. Nonetheless, it definitely happens for one reason or another and it's not something worth complaining about unless you're given some sort of a priori quality assurance.
I'm sure there are thousands of projects on Github which have a 0% response rate for PRs/issues. This isn't bad -- it just is. It's entirely someone's right to post a project and forget about it, regardless of how popular it got later on. Radio-silent projects will almost never get popular, since there's an implicit meta contract around support, feedback, etc.
That's not true in every case. For instance you need to keep pools fenced in, in most location as they are considered an attractive nuisance and you are liable if children jump into them and drown
The next time someone asks me why I'm choosing a proprietary solution, rather than one of the many fine open-source options available, I'm just going to point them to this comment.
Nope, not everyone can. And not everyone using it can fix it. And certainly not everyone can fix something to the standards that maintainers might demand.
> Therefore if an open source project maintainer is giving you their time and patience then you better be extra polite and grateful to them.
If I'm bothering to try to help them with their project, they owe as much 'politeness' and 'gratitude' back to me as is expected of them. It's a (minimum) 2 way street.
They might (morally) owe you this if they used your contributions. Otherwise, they owe you a (voluntary) politeness and gratitude that any human owes to any other human, but nothing more.
> But once you call it an open-source project, and you have docs and a roadmap and an issues page and stuff, you're making an implicit contract with people who use it that it will do a reasonable job of solving the problem it claims to solve. The user is choosing to use it over other alternatives and investing time learning and integrating it, so it doesn't seem at all unreasonable to me for them to be frustrated when they realize that due to some bug or limitation it doesn't actually solve the problem for them that it claims to.
Actually it does seem unreasonable to get irate at the developers when fitness for use is explicit in the license that enables use of the software in the first place. Open source licenses in general and the Python license in particular are very clear about this. The Python 3.7 license has the following term in section 4:
4. PSF is making Python 3.7.0 available to Licensee on an "AS IS" basis.
PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF
EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR
WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE
USE OF PYTHON 3.7.0 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.
If you use Python 3.7.0 and it displeases you, that's just part of the deal. On the other hand you do have the right to make your own copy and fix it to serve your purposes.
Most open-source licenses explicitly say that the software is provided as-is, and there is no warranty, express or implied, nor any obligation to continue to provide support or for it even to work.
The user is indeed choosing to use it over other alternatives; they are choosing to use it, and should make that choice on the basis of their own evaluation of the functionality and stability of the library.
> Most open-source licenses explicitly say that the software is provided as-is, and there is no warranty, express or implied, nor any obligation to continue to provide support or for it even to work.
Certainly, but notwithstanding those disclaimers, if the project's README or homepage describes it as intended and fit for a particular purpose, the user invests some time into learning to use the code in question based on the description, and it turns out that the description was... shall we say, overly optimistic, isn't the user entitled to be pissed off at the maintainer?
There may not be any legal liability, but the maintainer can incur social obligations by fostering expectations.
As an analogy, what do you think will happen if you tell someone you will help them move their stuff to a new apartment and that you'll bring a dolly, but you bail on them, or even just don't show up[0]? They chose to rely on you to provide the dolly rather than find some other alternative, after all.
So of course social obligations aren't something you can be sued over, but they are indeed real, and ignoring or violating them does have a cost: People get pissed off at you, which they may choose to express uncouthly in your general direction or vicinity, and your reputation suffers.
It is worth noting that this is far from a blank check for them to hurl invective at you. Their reputation may suffer as well, depending on just how uncouth they are.
Such is life.
[0] I am NOT saying that GvR has done the equivalent. In point of fact, he has left no outstanding commitments behind, and has fostered the growth of a robust group of core committers that are well up to the task of continuing to steer the project in his stead, though perhaps without his particular aesthetic sense.
Yes. The honestly somewhat dodgy no-warranty clauses in open-source licenses have always been justified on the basis that unpaid volunteers can't afford to be exposed to (potentially very serious) legal liability for their work. It's a bit astonishing that now they're being presented as a supposed reason why OS devs never have any ethical responsiblity to their users (beyond refraining from active malice, presumably?) (And in case it needs saying, no-one is suggesting that devs have an unlimited responsiblity to serve or take shit from users, or that users don't have reciprocal obligations.) By that logic the many sleazy Kickstarters, scam PACs, do-nothing gravy-train charities and the like that manage to stay just this side of the law are also all fine and wonderful.
You open implying that the original commenter's grievance in untrue outside of "throwing up some code," but at the end you say the opposite, and agree that it's "no excuse for being rude to them." I think you agree the original comment basically represents the truth, but you want to offer an elaboration on the complexities -- that's great, but why present your comment as a rebuttal?
I like your point about 'payment' not being a magic excuse for switching from not-rude to rude.
I don't accept the food analogy. You need food to survive, and you might need it free if you get stuck in life. You don't need free software - it's a bonus.
You mentioned the food-poisoning suing example - IA(also)NAL but if you put free software online without everybody's favourite "AS IS" block at the top, I believe you're on the hook if your software doesn't behave properly, so it looks to me like the law agrees with your notions.
Personally, I find the expectations over people offering software for free to be, broadly speaking, obnoxious - I definitely have a chip on my shoulder about it and I know that's coming out in this comment, so, apologies for the out of the blue railroading; your comment is the one that got me to articulate all the above, so, thanks.
> IA(also)NAL but if you put free software online without everybody's favourite "AS IS" block at the top, I believe you're on the hook if your software doesn't behave properly
That's a complex question about implied warranty that probably is affected by whether or not you are meet the legal standard to be considered a merchant of the type of good/service provided and other factors (and the AS IS block definitely discourages people to sue, but you may not actually be able to disclaim the warranty involved, so it may not get you off the hook.)
> if you give someone free food and it makes them sick, are they justified in getting mad at you? I think most people would say yes.
It's is more like people having an allergic reaction to otherwise perfectly safe and free food and complaining that you didn't take their allergy into account. And that you should go buy them some more food but made without the offending ingredient and with the sauce on the side.
That depends on the license. Most open source licenses state explicitly that you use the software at your own risk, and that the author promises you nothing and owes you nothing.
So, we insist open-source software developers to keep their "implicit contract", but we (as society) allow companies to buy companies that develop and maintain open-source to close-source it or just close the entire establishment? Without legal consequences.
Companies that shut down open-source dev teams are at least usually honest that that's what they're doing at the time that they do it. Open-source projects that actively evangelise—by extolling their community and documentation, presenting polished websites, in-app screenshots and shiny video demonstrations—then fail to make an adequate effort to serve and relate to the userbase the project has intentionally drummed up are not being similarly honest. If you don't want to serve the users, quit or turn off the evangelisation.
I don't understand how Guido van Rossum's message was interpreted as "he doesn't want to serve the users". His message said (to me) that he will continue, but he will not make decisions.
> Companies that shut down open-source dev teams are at least usually honest that that's what they're doing at the time that they do it.
This sentence implies that Guido van Rossum did something worse (than these companies) today. Is this what you are saying or I misunderstood?
BTW: I don't know him personally. I don't use Python regularly and I don't have any knowledge or position on Python's developers struggles and disagreements (if there are any).
I'm not commenting on GvR or GvR's behaviour at all. The discussion took a more general turn, with people seriously suggesting that the developers/maintainers of high-profile, publicly-evangelised open-source projects don't have any ethical duty to support or engage politely with their user base even while still in post. Obviously van Rossum is completely entitled to step down, certainly since there will be others to pick up the reins.
>But once you call it an open-source project, and you have docs and a roadmap and an issues page and stuff, you're making an implicit contract with people who use it that it will do a reasonable job of solving the problem it claims to solve.
Not at all. If I do all that, maybe I just did it for practice? Maybe I get bored or RSI and quit developing software? Nobody owes you anything, regardless of what they've offered you prior.
A contract requires an exchange of value in order to be binding. Using free software has no exchange of value, so there is no contract, implied or otherwise.
Even more extreme, consider that companies that do charge money drop the ball constantly on security/privacy, and basic quality. And yet they continue growing, maybe having a bit of churn.
I think there's something about generosity that just attracts entitled bullies/leeches because they see it as an opportunity to "win" against people who are
"foolish" (aka "weak") enough to work for free. Sadly sometimes the generous are duped into considering such requests out of curiosity or politeness, which leads to burnout or worse.
It is just selection bias. People that start and maintain OSS are on average more helpful and nice than people that don’t, hence the interaction.
A similar effect exists in relationships. If you are ‘nice’ then your potential partners include both other nice people and horrible people, because generally a horrible person will not tolerate another horrible person. Hence, you see nice people in relationships with horrible people more often than one would hope.
This is the number one thing making me lose interest in some projects I maintain. That toxic subset of users who expect free support debugging their applications is terrible for motivation, not least because most of them won’t even apologize when the problem turns out to be something they did.
I think it's deeper than just 'programmers today'. It's an important life lesson for people pre-disposed towards niceness to learn. Most people aren't thoughtful or considerate or fair. They just want to maximise benefit for themselves and their family. You're pushing a free product - so to them it's 'worthless' and they can treat you like trash.
Figure it out sooner rather than later or you'll be walked over for the rest of your life.
It's the same behaviour of ordinary users, in general. A developer who uses your library is, basically, a user. They see your work as an obligation, not as a gift you are giving to everyone.
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.