Guido blames social media for his decision to abandon the supervision of Python

Sounds like going forward, anyone who wants to seriously lead a project will need to devise a way to deal with this.

It's fine to lament the "hate" and "trolls" that are present online. (And it's also a very easy shot to take, by the way- no one will seriously disagree with it.) But assuming those are going to be around for at least a while longer, if not forever, to withstand it long-term you need to outright ignore it, or decide the things people say don't matter, or something.

It is true that each of us is responsible for what we say, online and elsewhere. And it is true that many people do not honor that responsibility, particularly online. It is also true that each of us is responsible for how we respond to what people say about us, online and elsewhere.

Although the article was mostly about this social media issue, watching the attached video I found Guido's statements about diversity and unconscious bias in Open Source to be a much more interesting part of the interview. (around the 23 minute mark)

Quote from Guido:

If you say "our project is open, anybody can come and join us, anybody can contribute", you are really underestimating the issues. Because it is not just joining the project that's the problem, it is staying in the project.

Which means you have to feel comfortable exchanging emails and code reviews and what-all with people that you don't know personally but you communicate frequently online.

And that sort of communication requires that everybody has respect for each other, and that respect is often missing because of unconscious biases, where guys and sometimes even women, who believe that they have no bias, don't realize that there are small differences in communication styles between men and women, (sometimes they are large differences) that just make it harder for women to join a particular community.

Because it's not just about writing the code, you have to sort of stand up for your code, defend your code, and there is a certain male attitude there that is endemic in many projects, where a woman for example would just not feel comfortable sort of claiming that she is right, that she has the correct insight to decide or to choose a solution, while a guy who knows less than that woman might honestly believe more in their own being right, and so they present a much more confident image. And so they have a much easier time even when they are not all that competent. As long as they present confidence they might get their inferior solution adopted.

A woman will more likely feel that she has to have a perfect solution and a perfect understanding of the issues, why it is a perfect solution, before she will even submit a patch. I am doing a fair amount of mentoring of women specifically, and I found that sometimes women I am mentoring will ask for my approval on every step of the way. They will say "I want to file an issue on the bug tracker but I'm afraid of the negative backlash when I put the issue in, can I tell you what I want to write the issue about?" That is charming, but and I always tell them "just put it in the tracker already! your head is not going to be bitten off, you will got honest feedback, and whether the feedback is 'that is a good idea' or 'that is a bad idea' it will be fine". But I'm sure a guy of the same skill level would not hesitate to just put the issue in the tracker. It is a bit of an attitude and mentality difference which makes it much harder for competent women to get started and stay afloat in this community where the male attitude is the default attitude. Because if someone presents that uncertainty, they are much more likely to get ignored or rejected.

> Who? I haven’t heard anyone express a willingness to take up that mantle.

There are many companies and projects who claims to maintain an internal version of Python 2.7. Maintaining after all is not so hard, at the end you only must make sure it compiles and connects to the neccessary APIs.

For many of these things indeed it is about the internal implementation and not about the language itself (although the language itself has many features limiting optimizations as well).

The main problem is that modules are compiled against the CPython implementation and the CPython API. These inefficiencies can never be fixed without changing the CPython API. However, changing that API means breaking all the modules that are compiled against that API.

This is also the reason why other interpreters besides the CPython one have so much trouble supporting all modules. They basically need to either rewrite the module code or support the (very inefficient) CPython API.

They could have changed the API to allow for much more efficient Python programs when they made the breaking transition of Python 2 to Python 3. However, instead they changed only a very small part of the API (the strings/unicode part) and left everything else intact. This meant it was easier to change code to support Python 3, however, it also means the actual benefits of switching to Python 3 are very limited while still breaking every single module that was compiled against Python 2.

This basically brings us to todays situation where billions of lines of code need to be updated to work on Python 3 (many of which will never be updated), while basically barely getting any benefits for doing so.

Yes, improved unicode support is great and I won't argue that it is an improvement, but arguing that it's worth millions of hours and millions of dollars wasted on upgrading code is a very hard sell.

Breaking backwards compatibility is very, very dangerous for popular projects, and it is something that should be taken extremely seriously. The team behind the Python 2 to Python 3 transition clearly did not do that, and the entire Python community has paid the price for that. The "print x" thing makes it extremely obvious that they did not realize the huge impact of their decision to break backwards compatibility. It is a minor thing that fixes a problem that really wasn't there to begin with, but it's a minor thing that breaks almost every single Python 2 program ever written. It's just ridiculous.