“I'm basically giving myself a permanent vacation from being BDFL”
mail.python.org
mail.python.org
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.
Like a certain other BDFL occasionally does?
It almost feels like hero worship.
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 also prefer people who role model nonviolence for future developers.
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.
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.
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.
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.
My understanding is that the person being derided here isn't even a kernel developer.
$ git shortlog -s --author Sievers --before 2012-07-06
339 Kay Sievers
$ git shortlog -s --author Sievers --after 2012-07-06
12 Kay SieversIf 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.
You and Linus and all his fanboys will no doubt say the kernel is better off without us.
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.
So, let's ask ourselves, is the term "dickhead" personal? Does it relate to a particular person? I don't see it relating to anything else, so I'm going to go with "yes" on that one.
But I could be missing something. What do you think it relates to?
> 2. of or concerning one's private life, relationships, and emotions rather than one's career or public life.
A much more relevant definition in this context don't you think? It's their public work being attacked, not their private life.
And then people keep wasting his time insisting on a bad idea
Cultural differences and all that. A good 'perkele' will be enough to get the point across in most cultures, even if some leave a bit disappointed.
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...)
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.
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 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.
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.
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.
> 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.
How? Which parts exactly?
> It's also a culture of de-humanisation
Again, how?
I find it creepy that without any specific examples provided you would report them.
Surely that creates a toxic culture.
It's interesting that making a complaint is seen as a negative thing to do: if there's no basis for the complaint no action is taken. Action is only taken - the compaint is only negative for the HCP - if the HCP has done something wrong.
> and seeing how the staff was venting, talking and joking about patients - once the doors were closed. I was very shocked,
The standard you walk past is the standard you accept.
Have a read of the reports I mentioned to see where this toxic culture leads.
Here's mid Staffs, but they all say the same: Mid Staffordshire: https://www.gov.uk/government/publications/report-of-the-mid...
> During the course of both the first inquiry and the present there has been a constant refrain from those charged with managing, leading, overseeing or regulating the Trust’s provision of services that no cause for concern was drawn to their attention, or that no one spoke up about concerns
People need to speak up. And when they do speak up, they need to be listened to.
> Negative culture
> While it is clear that, in spite of the warning signs, the wider system did not react to the constant flow of information signalling cause for concern, those with the most clear and close responsibility for ensuring that a safe and good standard care was provided to patients in Stafford, namely the Board and other leaders within the Trust, failed to appreciate the enormity of what was happening, reacted too slowly, if at all, to some matters of concern of which they were aware, and downplayed the significance of others. In the first report, this was attributed in a large part to an engrained culture of tolerance of poor standards, a focus on finance and targets, denial of concerns, and an isolation from practice elsewhere. Nothing I have heard in this Inquiry suggests that this analysis was wrong. Indeed the evidence has only reinforced it.
The first point in the executive summary to the Winterbourne View report says this:
> The abuse revealed at Winterbourne View hospital was criminal. Staff whose job was to care for and help people instead routinely mistreated and abused them. Its management allowed a culture of abuse to flourish. Warning signs were not picked up or acted on by health or local authorities, and concerns raised by a whistleblower went unheeded. The fact that it took a television documentary to raise the alarm was itself a mark of failings in the system.
Staff didn't go to Winterbourne View and immediately start punching people in the face. The abuse started with a culture of dehumanising these people, and closing off the wards to prevent criticism.
> The Serious Case Review also sets out very clearly that for a substantial portion of the time in which Winterbourne View operated, families and other visitors were not allowed access to the wards or individual patients’ bedrooms. This meant there was very little opportunity for outsiders to observe daily living in the hospital and enabled a closed and punitive culture to develop on the top floor of the hospital. Patients had limited access to advocacy and complaints were not dealt with.
Shocking because they were dehumanising or shocking because they were unexpected?
> and that were so shocking they could only be delivered behind closed doors.
My take is that it simply meant out of earshot of patients - and that's basic professionalism - not a sign of dehumanising patients.
They clearly weren't trying to hide their conversations from new staff.
> It's interesting that making a complaint is seen as a negative thing to do: if there's no basis for the complaint no action is taken.
I'd be extremely surprised if that's the case.
Even in the tech world complaints are treated seriously enough that people's lives are negatively impacted regardless of whether there is any basis.
> Have a read of the reports I mentioned to see where this toxic culture leads.
I've read your excerpts and can see no relation to the situation we are discussing.
Once again how does venting or making jokes about patients lead to a lower standard of care?
> The standard you walk past is the standard you accept.
And the parent poster made absolutely no comment about poor standards of care. In fact the implication was clearly that there was a high standard.
Culture is so important that the Mid Staffs report include an entire chapter about it. You've said that venting is a way for staff to cope with a difficult job. That has already been called out as harmful: https://assets.publishing.service.gov.uk/government/uploads/...
> Aspects of a negative culture have emerged at all levels of the NHS system. These include: a lack of consideration of risks to patients, defensiveness, looking inwards not outwards, secrecy, misplaced assumptions of trust, acceptance of poor standards and, above all, a failure to put the patient first in everything done. The emergence of such attitudes in otherwise caring and conscientious people may be a mechanism to cope with immense difficulties and challenges thrown up by their working lives.
They go on to say:
> A caring culture
> In addition to safety, healthcare needs to have a culture of caring, commitment and compassion. It requires the hard lessons of a Stafford to realise that it cannot be assumed that such a culture is shared by all who provide healthcare services to patients. What are the essential ingredients of such a culture? They surely include:
> Recognition of the need to empathise with patients and other service users;
[...]
> A commitment to draw concerns about patient safety and welfare to the attention of those who can address those concerns
I'd suggest that you can't empathise with a patient if you're being unpleasant about them behind closed doors.
My context is health care provided in English MH settings, usually in-patient, usually paid for by the NHS but not necessarily in an NHS hospital or with NHS staff.
> Once again how does venting or making jokes about patients lead to a lower standard of care?
Venting is an HCP placing blame for an event on the patient. This frames future incidents and the responses to those incidents. It makes it more acceptable and more likely for staff to use restrictive practices, and it de-emphasises the skills of de-escalation.
There is wide variation in the use of "prone restraint" in England. Some hospitals do not use it at all. Others use it frequently. Prone restraint can lead to death, so it's important that we understand this variation. One of the differences, but not the only difference, is the culture.
Imagine you're detained against your will in a mental health hospital.
Nurses Ann and Bob have the legal power to get a team of people to force you to the ground, hold you in prone or supine restraint, remove items of clothing to expose your buttocks, and inject a rapid tranquillisation medication. Again, all of this is against your will.
Nurse Ann says, behind closed doors during a team meeting: "Holy crap sheepmullet's anger has been out of control all this week. They wanted Section 17 leave for Christmas[1], but that wasn't granted, and I've got to tell them later and I know they're going to kick off again. They're just so angry at everything I say to them, and I know this is going to send them off the edge."
Nurse Bob says, behind closed doors during a team meeting: "sheepmullet has applied for section 17 leave. This was not granted. I have to tell them later that it has not been granted. I know that sheepmullet was really looking forward to Christmas with their family, and that they will be very disappointed that they're staying in hospital. I've struggled to talk to sheepmullet in a way that helps them contain their anger, and I'd like some advice about how to break this bad news in the best way."
There's not much that is actionable in a complaint from Nurse Ann. The comments aren't shocking. Ann's comments are likely milder than those mentioned in the original comment I responded to. But that approach is more likely to lead to prone or supine restraint, rapid tranquillisation, and a spell of seclusion. These are significant actions and should only be done as a last resort. Prone restraint has the potential to cause death.
Nurse Bob is making use of Soft Words from SafeWards[2], which is used in a range of MH settings, including "Secure Units"[2]. We're pretty sure this approach reduces the need for restraint, rapid tranq, and seclusion.
Imagine you get to chose who looks after you: do you pick Ann or Bob?
> Even in the tech world
Look at airline safety investigation where errors, even errors that kill, are not punished but are sources of learning. This should be true of healthcare, although it isn't always. The solution is not to avoid ever making complaints, but to keep making complaints and force the regulatory bodies to change their complaint handling.
We don't know what the comments were, and obviously if they're innocuous you don't report them. But, and this is really clear from all the investigations and research we have: you need to report disfunctional culture and leaders need to listen and act on those reports.
You seem to be saying that "shocking comments" aren't really shocking, and that non-shocking comments shouldn't be reported. I'd agree that you don't need to report stuff that doesn't need to be reported, but does that need to be said?
> Once again how does venting or making jokes about patients lead to a lower standard of care?
Look at what happened at Winterbourne View. People with intellectual disability were being tortured. There was a collapse in compassion. How did that start? How did we go from a 24 bed ATU providing care to a place where multiple staff felt it was okay to punch patients or trap them underneath chairs or pour mouthwash into their eyes? That started with staff who dehumanised their patients, and that dehumanisation starts with "shocking comments" delivered behind closed doors. A culture of abuse starts with staff thinking it's okay to badmouth patients just because they're behind a closed door. "Canteen culture" - staff sharing unacceptable views behind closed doors - is a widely recognised source of toxicity.
> In fact the implication was clearly that there was a high standard
That's what the midwives at Morecambe Bay said, that this was a good unit providing high quality care with the patient at the centre of everything they do. They were wrong. It was providing such poor care that babies were needlessly dying.
That's what the managers at Mid-Staffs said. We had no way of knowing care was so poor. Everything we had told us it was okay. They were wrong, they had a lot of indicators (including complaints from patients, relatives, and staff) to show that there had been a collapse in compassion in their hospital.
[1] apologies if Christmas means nothing to you. Substitute for something else significant: child's first day at school etc.
[2] http://www.safewards.net/managers/evidence
[3] these units work mostly with people who've been imprisoned or arrested after committing a criminal offence - they work with very ill people who are more likely to be violent. https://www.centreformentalhealth.org.uk/secure-care See also forensic services: http://www.nhsconfed.org/~/media/Confederation/Files/Publica...
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.
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?
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.
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.
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.
Thanks, Guido, for the good times!
But the aesthetics of a whitespace language just don't jive with my 30+ years of experience writing code. No matter how many times I try over the past few decades, I just can't get passionate about writing Python code. I know its power, and I totally grok its value to our industry - but for me, Lua is just far more elegant, even if it doesn't ship with all of Pythons' goosebridles. Lua is my go-to scripting language; I only ever use Python if I have to - i.e. its enforced on me by others.
I really do try to get over this personal handicap, often enough, but the moment I have to start thinking about indentation I just lose all the passion and it starts feeling like a drag. What a dilemma, because I know it has been used for many, many great things .. I just wish I could get over my aversion to white-space'ing things all the time. I've tried editor after editor (well, expect the Python-specific things), but it just doesn't click.
Ah well.
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.
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.
However, that breakage does mean that you have to at least read the code a bit. You either get to avoid a potential security flaw or gain a deeper understanding of an algorithm.
Fixing syntax does not break your ability to learn an algorithm but it will get you closer to its description.
With Python you are generally SIL not SOL.
I've been writing Python for years and never had this problem.
Three things that are key in Lisp: Symbols, environments and lexical scope. Python has none of these.
Python 3 makes it worse by adding some declarative stupidies nonlocal and global:
Personally I really miss defining for-loop index cars in the for-loop syntax.
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.
x = function(x) return x*x end
Not that it really matters though, bridges still get built.
def f(x): return x * x x = lambda x: x*x
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.
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.
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?
-- To quote Peter Norvig, Director of Research at Google and author of multiple books on AI and Lisp.
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.
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.
At the same time I can’t wait for the next language to replace it.
Perhaps that was the second scraper.
I believe that is the case yes. However correct me if m wrong.
From https://www.vanityfair.com/news/2018/07/valley-of-genius-exc...:
> Scott Hassan: In the fall of ’95, for some reason, I started hanging out with Larry in his office. . . . At the time, Larry was trying to download a hundred pages simultaneously. And I was fixing some of the bugs that he was having with Java itself, and this went on for weeks, if not months. And I remember thinking, Wow, this is insane!, because I was spending a lot of time fixing this underlying tool. And so one weekend, I just took all his code, I took his whole entire thing, and threw it all out, and rewrote the thing that he’s been working on for months very quickly—over a weekend—because I was just sick and tired of it. I knew I could get the thing working if I used a language I knew very well, called Python. I wrote it in such a way that it could download 32,000 pages simultaneously. So Larry went from barely downloading a 100, to doing 32,000 [pages] simultaneously on a single machine.
Fun "fact": I need to check my facts, but it could be that the very first Google was written it it, too :)
Checked:
https://www.google.co.in/search?q=what+language+was+google+s...
PEP 572: Python assignment expressions has been accepted
(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 :-)
- pattern matching
- inline exception catching
- path inclusion in the built in
- more functional tooling
- lazy keywors
That were BDFL-blocked, will go back to be debated in the mailing list in the next months.
And if yes, will the community stands by its root or create a new era ?
The consequences of which we will only really see in 10 years.
Guido as done an incredible job at being the boogie man, keeping the language simple and readable. It's a hard job.
Can we pull it off ?
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).
Python does that with tuples:
a, b = b, a
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"
make_noise :: Animal -> str
make_noise Duck = "quack"
make_noise Dog = "bork bork"
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.
It's why it's hard.
</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.
[foo(y, y) for x in xs for y in [f(x)]]
There's so many cases (arguably including the problem this PEP was designed to solve!) where having a real inline closure is just far more readable than having to arbitrarily break every single thing that happens to need 2+ expressions out into named blocks out of sequence.
Other things in Python are either simply a result of the language's age and history, or have real technical pros and cons, but that one irks me because it's an artificial limitation chosen for no reason except aesthetics.
God please NO!
I would KILL not to make that happen. So many devs abuse those in every language that has that. Even lambas get sometimes abused in Python (and I have a few examples in our codebase unfortunately). Expanding lambdas' scope is the LAST thing I want in Python, this would just lead to worst codebases, with nearly 0 benefit.
If you want to do something that needs 2 expressions, just create a goddamn function and name it for god's sake.
Sorry but I had to say it, I think the lambda limitations is one of my favorite feature in Python.
It 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’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.
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.
"Shooting yourself in the foot is your fault for not using a linter that detects accidental misuse of assignment!"
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.
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.
Wanting your pet coding preferences to be enforced by criminal law is a sadomasochistic fantasy.
Thinking that putting a seatbelt will prevent death in a crash is foolish, and yet they are still 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.
Did you reply to the wrong post?
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 imagine Kotlin had that feature; then we could just do the following:
when(foo = foo()) {
is Bar -> foo.x
is Baz -> ...
}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.
https://doc.rust-lang.org/book/second-edition/ch06-02-match....
match foo() {
Bar @ foo => foo.x,
Baz => ...,
}Conditionals need an expression, and assignment fits the bill, so it works.
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.
if(malloc(10000 * sizeof foo) == NULL) {
// Error processing
} // No need for an else branch here. int success = NULL;
if(success = malloc(...)) {
}
if(success = malloc(...)) {
}
if(success = malloc(...)) {
} char* p = NULL;
if (p = malloc(...)) {
...
} guard let value = myOptional else {
// Handle absence
}
// Use value
if let value = myOptional {
// Use value
}It's very good.
You mean compiler right? The compiler should be warning for things like this, not relying on 3rd party tools.
So, yes, if you're using a custom compiler, you kinda are to blame for shooting yourself in the foot. Just use the official binaries!
You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway.
They only did it if the := is at the root level. The following is completely legal:
if match := re.search(pat, text):
`print("Found:", match.group(0))
[y := f(x), y**2, y**3]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?
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!
But the best solution is probably to just drop the = as an operator altogether.
s/\$LANGUAGE/C/
(Assume for the sake of argument it’s some more reasonable example like "if (x = re_match(foo, bar)) {...}")
At least the systems I've seen need a extra (()) around = to disable the warnings and notify the reader that you're not just comparing for equality.
if (auto x = re_match(foo, bar); x.has_value()) {
Throwing warnings for "common code" would be uncharacteristic.
Thanks Guido for fantastic language. I wouldn't find love for programming if it wasn't for you.
You clearly never had exposure to a PHP codebase. If people can trip up, people will trip up.
But c-style assignment in Python was never going to happen, not should it have.
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.
x = stuff
while x:
x = stuff while true:
x = stuff
if not x:
break 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
https://youtu.be/tzFWz5fiVKU?t=2785
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.
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.
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).
Leading a large open source project must be terrible in this age of constant outrage :-(
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.
https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/
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. ;-)
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.
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.
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.
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.
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.
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.
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.
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.
Because they're already the senior. CEO said it shouldn't be that hard, and besides, they only wanted to pay $40K/yr.
Or did you forget the /s...
Yep. It's been a long day after a particularly long week. I will take a break from HN, too much on my mind. Thanks for the reminder.
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.
Nobody else but you alone can ensure that your project is managed and developed properly.
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.
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.
no one promised you anything. you merged some code into your project. now deal with the consequences. be responsible for your work.
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.
> 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.
Pope John XXIII
ahahaha
Yeah, tough. Fix your code
That's the attitude some maintainers need in cutting unreasonable requests.
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'.
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.
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.
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
“A word aptly spoken is like apples of gold in settings of silver.” —Proverbs
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!
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!)
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.
The sad part is: I lost the email in a transition from one machine/set of floppy disk backups to another.
Guess they went out of business before they could typecast all these nasty empty strings.
I'm really sorry you ran into this issue. To make things better,
I've given you a full refund.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?
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.
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.
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."
I don’t support having return at all. Statements that are not expressions are a mistake.
Syntax irregularities are anti-practical.
Cro (https://cro.services) is a set of libraries for building reactive distributed systems. Comma IDE (https://commaide.com) is an IDE for Perl 6, based on the JetBrains IDEA platform, now in (paid) beta.
If you want to keep up-to-date on Perl 6 development, check out the Perl 6 Weekly (https://p6weekly.wordpress.com).
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.
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.
this shows a superficial, almost entertainment-industry sort of view of a software development lifecycle..
in the latest Ubuntu Bionic with apps, building right now on a local machine, I see 143 python-xx packages installed and 43 python3-xxx ..
saavy package authors use import future and six to side-step the whole issue, while core maintainers struggle, and outsiders invoke a mob voice
Python 2.7 for LTS
Meanwhile C22 work is ongoing.
FTFY
There are almost no vendors left offering C89 only compilers.
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.
Since Google couldn't convince folks to let them make Python faster, they created a NEW language instead.
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.
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 3 implementation was a step in the right direction, but the decision to allow the old language co co-exist with the new one and to break backwards compatibility between the two (for instance 'print') in places where it didn't need to break makes no sense to me.
A lot of goodwill got burned with that.
Fail fast. It's better to break right away than having false senses of security. There is always __future__ too.
Ultimately, it's up to certain stakeholders to hear arguments and make calls.
In Python land, there is this saying "we are all adults here".
Being an adult also means avoiding creating needless drama.
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.
This analogy does not work in software.
I agree with the idea you should give power only to people that don't want it.
I think guido was the right person in power.
You can do something that people disagree with, even something that you think is the best for them, and still be benevolent.
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.
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.
[1] https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_c...
I think social media is responsible for breeding this sense of entitlement among people.
And entitlement.
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 ..
Too deadpan.
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.
I mean it was bound to happen at some point, but I am really disheartened that it happened in this way.
Sometimes less is more. Python is turning into more is less. It doesn't need to be everything to everyone.
Edited to remove inadvertent backhanded compliment
When I'm on vacation, I'm working on me. Not for the company.
Maybe he should have pushed harder on his Royal Prerogative to move things forwards
This is just my personal opinion.
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.
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.
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.
Thanks Guido for giving us Python!
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 am glad that Python is recognized as the quality language it is.
Perhaps it's synchronicity that in other news this week Elon Musk triple hearted Python, https://twitter.com/elonmusk/status/1016002749446516737.
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.
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.
and in case it wasnt clear i was referencing the US tripartite governance model
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.
Guido is not asking Python to live without a dictator. Guido is asking Python to learn how to live without Guido, so that Python may outlive him.
This is a tale as old as time. Apple lives on with only memories of Steve Jobs. The United States lives on with only memories George Washington.
For some inspiration I'd recommend listening to the track "One Last Time" from the Hamilton musical:
"One Last Time" - Hamilton At The White House #ObamaLegacy https://www.youtube.com/watch?v=uV4UpCq2azs
Original Broadway Cast Recording on YouTube https://www.youtube.com/watch?v=pEqnXNsAFL8
Original Broadway Cast Recording on Spotify https://open.spotify.com/track/0Iys022UwQ8xBfxE1g4nWZ
I think that remains to be seen.
I'm sure there's more you could have written, why hold back?
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.
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.
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.
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.
Respect, Guido.
- What was fun 3 years ago isn't anymore
- That feature that was useful to your customers is no longer serving purposes
- It was about new feature, and now it's about maintaining compatibility
- ...
There is no real cause to "treat", you just need to adapt to the new environment you are facing.
> 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.
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.
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!
[0] https://legacy.python.org/search/hypermail/python-1994q2/104...
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.
Also, an apology for the way this turned out would be seemly.
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?
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.
It's kind of cold to me, but I know this field is not filled with the emotional types...
Completely tangential, but the density of negatives in that sentence was nothing short of majestic.
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."
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.
The market didn't give the world any language nearly as readable and approachable for non-programmers.
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.
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).
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.
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.
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.
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.
This is that prompt.
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.
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?
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.
A lot of people actively enjoy and seek conflict.
Think apple did not fall too far from the tree :)
It's kind of funny to see someone worrying about sparing Linus Torvalds' feelings.
Maybe an environment that is more respectful and professional?
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...
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.
https://gvanrossum.github.io/pics.html
I prefer perl, but thanks for python!
Diversity is good always :)
Guido (1995) https://gvanrossum.github.io/images/Guido@200dpi.jpg
Austin Powers (1997) https://m.media-amazon.com/images/M/MV5BYWY1ZTdlZTEtYWRjOS00...
To the python community, I hope we can find a successful, democratic way forward.
To myself, public service is a good thing - try harder !
"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.
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.
Thank you, Guido, for putting the B in BDFL when you could.
It's a harsh confusing place and the absence of tooling and structure doesn't help.
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)
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.
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.
[1] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Will `with` start using this syntax instead of `b as a`: `with open('foo') as a:` == `with a := open('foo'):`?
Update: found my answer on the pep. `with EXPR as VAR` actually calls `EXPR.__enter__()` so it's not the same.
Seems very unnecessary to have both options.
I'm sick and tired of writing stuff like
m = f( <...> )
if m:
# do stuff with m
if m := re.match(...):
...
elif m := re.match(...):
...
case f <...> of
Nothing -> -- Handles the problem values
Just m -> -- do stuff with m
That's not it at all. The PEP even acknowledges that while `(a := b)` would be valid, it would not be recommended.
As he says, the bus is around the corner, and the reaper comes for us all - so governance is a key component of an institution.
Thanks Guido for all the fun that we made with python and eased the life of bankers :/
It is bad news, is Guido fine?
It has changed a lot of lives and will continue to do so for a long time.
Enjoy the vacation and take care of yourself.
"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.
Rough consensus is what you need here.
Why?
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.
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").
Languages generally do well when there is a sense of leadership and vision for where it is going. Consensus is terrible at providing both.
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.
I get so many bug reports like "This sux and you have to fix it!!!!" and even when I wake up on the right side of the bed, there's nothing I can do with those.
A calm discussion of what the developer is trying to achieve, what they expect to happen, what actually happens, and how I can reproduce will get a quick response from me 100% of the time.
That said, when someone open sources something there isn an implicit "contract" between the developers and users. The users' feedback helps the developers and in return they get something valuable. It's more of a group effort rather than some one directional flow of power. I've seen projects where these relationships weren't properly managed or where one group didn't appreciate the other and the end result is always the same: dead projects.
OSS maintainers deserve respect but at a certain point they have turned their hobby in to their career, complete with clients and marketing. If you are willing to trust an open source project for your livelihood than the maintainer also has an obligation to respect that.
Worse, it's open source. You are always free to do it your damn self if it's so important to your livelihood.
Rule 1: Nobody owes you jack.
Sure, but in the same sense "you pay" for eating a day-old egg salad sandwich you found sitting on a park bench. (Luckily, even using badly-written open source software generally has a less unpleasant outcome.)
Like open source, the chef -- who you have no relationship, connection or contract with -- is not under any obligation to guarantee either your satisfaction or survival.
If you want to reduce the risk to your livelihood, you should pay money for both your critical open source software and your egg salad sandwiches.
Some people downloaded it, built it and used it. Even added to it, where they liked.
Most people were like you.
I never share code any more.
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.
Figure it out sooner rather than later or you'll be walked over for the rest of your life.
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.
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.
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.
[1] https://digitalcommons.law.seattleu.edu/cgi/viewcontent.cgi?...
[2] https://www.huffingtonpost.com/entry/restaurants-that-dont-d...
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.
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.
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.
https://en.m.wikipedia.org/wiki/Duty_to_rescue
Read the last part about the elderly man who died in a bank and no one offered assistance.
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.'
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.
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.
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.
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.)
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).
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.
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.
Edit: fixed typo
IANAL
https://www.apache.org/licenses/LICENSE-2.0
https://opensource.org/licenses/MIT
https://opensource.org/licenses/BSD-3-Clause
https://www.gnu.org/licenses/gpl-3.0.en.html
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.
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.
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 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.
""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.
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.
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/
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:
https://www.scottaaronson.com/blog/?p=3875#comments
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.
(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.)
- "You don't have to do X but if you don't do X you're being a jerk."
- "Don't be a jerk."
If I don't do X, have I violated the license terms or not?
Excited to see what Guido wants to do next, enjoy it!
But he also had some specific stickups with some features -- like closures for example.
It’s sad to see how critics get in the way of an artist who just needs low-level things to be fckng done in a safe-enough way.
It's interesting that GvR seems to have been the first official BDFL
(regarding his style of communication)
Edit: Everyone is saying it is fine. Again I'm not saying it is not, but if it is, can you please update this part of the guidelines:
>Otherwise please use the original title, unless it is misleading or linkbait. Don't editorialize.
Have you seen comments made by them that indicate a change in policy other than those mentioned in the guidelines? Has there been a substantive change in the intent of the guidelines as currently written over time?
For X action to happen, Y percent of the pool of people in the Z list need to approve it.
Membership of the Z list is granted when W percent of the T pool approve it.
Modifying the rules of government of this repo can only happen when L percent of the R pool approve it.
And on and on...
I could imagine a city or state government actually having its laws encoded in Github, and Github itself enforces the governmental system of checks and balances. Congress. Senate. President. Veto. Overriding a Veto. Laws of succession. Elections. On and on.
Today, people over-leverage technology and under-leverage the fundamentals of club-building. Roberts Rules are about creating a protocol where people each take turns to talk, under a set of rules that gives everyone a chance to voice their opinions... but still allows progress and ultimately a decision to be made.
That's the important part: how to achieve consensus among a group of people. The ideas of democracy, discussion, minority votes, and rules of how to conduct the discussion are all important.
Some groups still use Robert's rules, but many people don't even understand what a deliberative body is meant to do. (IE: most people don't understand Congress's role in society anymore). Its basically been replaced by meme culture and Reddit moderators creating serfdoms and/or dictatorships.
No amount of code thrown at people mismanaging their relationship with other people will ever help people more effectively manage their relationship with those people -- it just creates artificial obstacles that further exacerbate or obscure the problem.
There is simply no combination or refinement of the logic OP proposed that would ever be perfectly sufficient to avert the need for human judgement in their scenario.
What if 51% of the project simultaneously reveal themselves to be alt-right fanatics who want to take the work in a new, fundamentally evil direction, ideologically aberrant to OP? Oh that's easy - OP can just step in with his admin privileges and disable their access. And that just underscores the point -- the original voting logic was a facade, and the original trust problem remained. The presence of that logic failed to solve any problem, the reality was always a true power structure that differed from the imaginary codified structure.
Perhaps one alternative would be for OP to give up admin rights entirely - but only a fool would believe a bunch of codified rules spread across a couple of software functions could ever perfectly mediate the complexities of a community of people in every possible scenario.
That's still a social problem.
What I want is that the mechanical process of doing code reviews, accepting pull requests, and orchestrating the Access Control Lists, and the membership of them, can be implemented by the code repo.
Rather than giving unfettered power to a small list of owners, who could literally do anything to the repo. And if they all get hit by the same bus, then we're SOL.
Heck, I want a Deadman Switch, too. If Github doesn't hear from me in 90 days, even after emailing me to get my attention, then ownership of this repo should be assigned to this other person. If that fails, on to this other person, etc.
"only a fool would believe a bunch of codified rules spread across a couple of software functions could ever perfectly mediate the complexities of a community of people in every possible scenario."
Or someone who has experienced such a system at a company, and wishes the rest of the world had similar functions.
Note that I'm happy to allow for escape hatches... Such as we could always Fork the repo.
"What if 51%"
Then I fork the repo.
What do you do if the 1 single owner of a repo turns out to be a fanatic?
You and twenty other people all fork the repo, and then debate ensues about who is the One True Repo.
I'm suggesting that there's a smarter way to handle the problem of a small number of people having absolute power over our repos.
And if you're smart, you leave in a provision for completely changing the governance, in case you screw it up. Or you just fork. Like we do today.
Now, it may be that you mean that the changes induced by technological solutions never actually affect some imperturbable "core problem" that is what people mean when they talk about "social problems". That would be a counterintuitive use of language but there'd be no sense in me attempting to persuade people to use language differently. Instead, what would be productive would be to identify what core, unchanged problem really does remain.
Have your debate in email, but then VOTE in a way that can be automated.
It's the governance of the repo that I want encoded. I make a pull request, and it's decided upon by the government system.
That needs to be encoded into Github.
And yes, "the very diverse governance models" is a challenge. One I think needs to be taken up, eventually.
I don't want one jerk to have the ability to ruin a repo. I don't want to have to fork a repo when the one owner dies. When I disagree with the owner of a repo, I'd like a process to resolve it.
And the solution is to trust Github (proudly owned by Microsoft) to be the rule enforcer? Hmm...
BTW, there's nothing wrong with small groups of individuals having power over repos - millions of small software projects are governed that way, with exclusive control of one person or small team of people over them. For the project of Python size and influence, it's not a good idea, but for many others it's fine.
> And yes, "the very diverse governance models" is a challenge. One I think needs to be taken up, eventually.
No, it's not a challenge, that is a natural diversity of life. Which should not be approached with one-size-fits-all attitude.
> I don't want one jerk to have the ability to ruin a repo.
With open source and proper distributed version control, it is not possible anyway.
If Github screws up any of this, you fork to a different location.
> BTW, there's nothing wrong with small groups of individuals having power over repos
I'm not saying that shouldn't exist.
I'm saying that's inappropriate for some use cases. I'm asking for an optional feature that I would want to use, sometimes.
> Which should not be approached with one-size-fits-all attitude.
Which is why I said that it's a challenge to handle the different use cases appropriately.
> With open source and proper distributed version control, it is not possible anyway.
I'm asking for a feature which makes it less likely that I'll have to abandon a repo for a fork, in some circumstances.
If you don't want the feature, or if you don't trust people who use that feature, you're free to fork.
Why are you going out of your way to shit on my feature request, considering it does you absolutely zero harm?
It's a complete non-sequitur. It's like saying "if you trust water company with delivering your drinking water, you should allow them to raise your children". Keeping bits in place (protected by crypto hashes so any shenanigans would be noticed by people holding copies of the repo very quickly) is not the same as letting them govern the projects. Technical and social functions are completely different. Moreover, the issue of trust and control are completely different - there are a number of people who I trust, but I don't let them run my life for me.
I don't want the ability to accept a Pull request.
I want three of the five owners of this repo to have to accept it.
I propose that Github automate taking the votes, and taking the action if the vote passes. And preventing the action unless the vote happens.
That way I can trust that nothing happens without the proper procedures.
Your comparison is absurd.
Can I fork your socialist utopia and form an authoritarian dictatorship?
I don’t see why this system would ever be beneficial to a real world government. We already have checks and balances, if GitHub did it all who decides how GitHub works? What’s the benefit?
> Why is representative democracy the best system for managing a repo?
There's also the issue of practicality. Voting on issues is a time and resource intensive process. It's just impractical to have everybody vote directly on every single decision.
> Can I fork your socialist utopia and form an authoritarian dictatorship?
> I don’t see why this system would ever be beneficial to a real world government.
- Nations have many orders of magnitude more resources than... Python
- Practically speaking the vast majority of people can belong to only a single nation, whereas most developers probably used a handful of languages in the last 24h
- Nobody asked to be born into a country, and most people on Earth can't simply choose a new one
- The decisions made by nations are literally life and death for millions of people
The relevant factors for determining the course of Python's governance model bear far more resemblance to your neighborhood restaurant's menu decisions than the ways in which governments are elected.
Sorry if this wasn't clear, but I think there should be different classes of users, with different powers.
No, your vote should not have the same power as someone who has carefully maintained Python for years.
But if there are nine peers, maybe they would like a bit of automation to help them
1) triage bugs
2) vote on actions
3) take those actions automatically based on the result of voting
> It's just impractical to have everybody vote directly on every single decision.
Different parts of code could have different protections.
Want to update the docs? Go for it! If we hate your changes, we'll just revert them.
Want to change the implementation of memcpy? Uh, you're going to get lots of reviews.
> government
How should a city government keep track of its artifacts? The documents it produces that have the authority of their office? Revisions to those documents? Approval over those revisions?
I'm saying technology might make their jobs simpler.
Sorry if this wasn't clear, but I think there should be different classes of users, with different powers.
A game could grant you the ability to edit its source code, after you complete the game. That's just a for-instance.
> Will there also be an option for pure democracy?
Sure, why not?
> Can I fork your socialist utopia and form an authoritarian dictatorship?
Mechanically, sure. There may be licensing problems, but that's true today.
> I don’t see why this system would ever be beneficial to a real world government.
If the real world government stores its web pages in GitHub, then the real world government can use this governance to handle changes to that web page.
Rather than letting a lone IT admin have root.
> What’s the benefit?
If you're comfortable with needing to fork a repo when the BDFL goes rogue and starts making changes you hate, then there's no benefit at all.
Doesn't he have any people he trusts in the inner circle of Python development? Would've been much better to have power slowly and uncommented slip into their hands. A process that could have been started years ago.
Feels a little like this: https://imgur.com/gallery/IYYmtqL
To me, it seems a restricted variant on the specific cases "if" and "while" would be good enough, without generalizing to more cases.
The exemples of assignment with "all()" and "any()" make me sad. Python had only one way of doing things, now it has two.
Reading Python code will be more complicated now than it was 10 years ago for newcomers
Edit : I'm sick of all the downvotes on HN. Everytime we post an opinion against the consensus, it ruins the karma, even if the comment is honest. And of course, I can't downvote people, since people keep downvoting me, I never reach the threshold to vote against any comment. The system is unfair to newcomers.
There is really nothing in the e-mail that indicates that.
I can only imagine the message it would send to recall the PEP. I guess it would confirm his decision in a most callous way.
Guido wrote the principles of Python, the principles should outlive his reign. :-)
That really isn't a fair comparison. This is about one person, not two opposing groups.
Downvoting was, long ago, supposed to be used to indicate trolling, incivility, not substantive, etc. Sometime recently, dang and sctb have ruled that downvoting for disagreement is now perfectly acceptable.
In any event, I agree it's become a terrible method of hivemind enforcement. Have an upvote.
As pg’s 2008 quote shows, that assertion is wrong.
Whether it should change now is a separate issue, but there seems to be no mood for that among the more active contributors to HN.
You are wrong about that: https://news.ycombinator.com/item?id=117171