As for the claim of "questioning [his] authority", isn't that a given? With or without social media. That's pretty much human nature. It's up to you to establish the tone and medium of how people interact with you. Linus, for example, is pretty much strictly email and most things go through one of the "inner circle" who are largely responsible for areas like networking. As brash as he can be, you pretty much know what to expect and you have delegation.
Honestly, I wonder how much of this goes back to GvR's handling of Python 3. This should go down as something to be studied for years on how not to do a breaking change. IIRC Python 3 was released in 2008. Here we are in 2019 with no end in sight for Python 2.7.
My favourite Python 3ism was the removal of the s and u string literal prefixes. In Python 2.0+, u'this is a string' was a Unicode literal prefix. It was removed in 3.0 for reasons that are beyond me (I know Unicode became the default for string literals) but then added back in 3.3 for backwards compatibility. Why remove it in the first place? It makes no sense. But this just went to the perception that the Python powers-that-be were removed from reality in their hubris.
Anyway, GvR... one can't help but respect his stewardship and contribution to Python. Please make no mistake about that. The weird thing about human nature is in situations like this, if the peanut gallery senses they're getting to you it only encourages them. Sad but true.
That's not correct. Numpy, for example, will not be supporting python2.7 starting January 1st, 2020 (https://docs.scipy.org/doc/numpy-1.14.2/neps/dropping-python...), and there are others in the process.
Python itself will stop supporting 2.7 on January 1st, 2020. (see https://devguide.python.org/#status-of-python-branches)
Has it been poorly managed? Yes.
Will a number of companies skip upgrading from python2 to python3 and instead rewrite it in Go or Rust? Absolutely.
But "no end in sight" is not an accurate depiction of the current state of affairs.
An end is in sight, is coming soon, and it’s sort of concerning that more folks haven’t realized it yet - https://pythonclock.org/
Google is still Py2 I believe, as is Dropbox. These are big Python shops.
I write Python. I don't see an end in sight, yet. There is, however, forward progress.
Dropbox migrated to Python 3. So did Instagram.
When tensorflow was released (november 2015), it was python2 only!
Python may not officially support 2.7 in 2020+. What's to stop someone else backporting security patches and necessary fixes as needed ad infinitum? I think you're underestimating just how little impetus there is to migrate from 2 to 3.
No idea what I did to deserve that tone. That site also gives a high level overview of the change, which is why I linked it.
> What’s to stop someone else from backporting security fixes as needed ad infinitum?
Who? I haven’t heard anyone express a willingness to take up that mantle. “Someone will probably support it by the end of the year” is not the most robust security model.
You can tell a lot about how a project is run and the people running it by their attitude to breaking changes.
Java, for example, has taken this very seriously. I mean it also explains why generics are kind of the mess they are but they didn't really have a lot of good choices here. What's more, people can compile older code with newer compilers by setting the language version.
Rust seems to be making the right noises. Since 1.0 I'm not sure if there has been any and their plan is to save those for major versions.
Perl 6... is an interesting one. Perl 5 actually had a lot of momentum but Perl 6 pretty much drove Perl into irrelevancy.
C# did make breaking changes but did it sufficiently early and they benefitted from the second mover advantage learning from Java's mistakes. IIRC C# added generics without type erasure in 2.0?
Python 3 was I think almost Python's Perl 6 moment. The only thing that probably saved Python from sliding into history was things like numpy/scipy, ML (eg pytorch), etc. Here's where the GIL doesn't really matter and Python's interface to C modules works really well.
For other applications people have (IMHO) started to move away from dynamic languages, something I personally support. The way I like to describe dynamic languages is you end up writing unit tests for spelling mistakes.
>Who? I haven’t heard anyone express a willingness to take up that mantle.
Tauthon  kind of fits the bill here. It's a fork of 2.7 with some backported features from the 3 branch, so they're in a position to backport security fixes as well. How well that arrangement holds up once the PSF officially drops 2 remains to be seen, but if anybody is in a position to keep providing support it's probably them.
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.
Nothing, it may even prove to be a business model, and vendors like Red Hat may be forced to do that anyway.
But back-porting security fixes to core Python 2.7 is one thing, but for many 3rd party libraries? Especially if they're GPL'd? That would take a coordinated effort, which again might happen, but hasn't materialized yet. So betting on that seems risky at the moment.
Python 2.7 EOL has been public knowledge for quite a while (and even pushed out once before). True, it is very convenient to forget about, and hope somebody else will sort out your tech debt.
To know what's going through the USA President's brain right now? Yes.
For a leader of a technical project? I doubt it.
If anyone's got a concern about what you're working on, and can't be arsed to go to the relevant forum or mailing list and say so there... well, it probably wasn't valid anyway.
Some (even if trivally small) barrier to entry for a technical community is good and useful.
Twitter on the other hand... maybe a non-existent barrier to entry is good for political discourse (that's another conversation), but I don't see how you're easily going to distinguish the wheat from the chaff on really wide-open forums like that for technical communities.
Even here the utility is dubious. A main product of Trump's twitter is food for comedians or useless information. I believe it is important to keep updated on politics and to hold people in power to high standards, but few of the things Trump has to say cannot wait a day.
Actually you could say that twitter availability is a cause of Trump expressing so many controversial statements.
"Today, it was my true honor to present the Commander-in-Chief’s Trophy—for the second year in a row, to the @ArmyWP_Football Black Knights. Congratulations once again on your historic victories, and keep on making us proud!"
i don't want to start a political debate, but blanket statements are rarely useful and can be easily verified.
I agree, I was sloppy in my comment and did no good at representing a good point. I am somewhat critical of the "we need to keep updated to the hour" mindset also because I tend to selectively focus on the negative sides. Before reentering this discussion in the future I should better focus on understanding my own positions.
Presumably because a tool like 2to3 could strip it out, leaving it in is confusing, and there already existed a better solution for forwards compatibility (unicode literals future flag). With hindsight, the wrong call, but not completely nonsensical from what I can tell.
There is no doubt that Twitter dramatically changed public dialog. It was/is revolutionary. Whether this revolution was a net positive or negative remains to be seen.
I'm highly doubtful. I actually believe that, despite the benefits, the net effect on public dialogue will be catastrophic. The overall attention span of people seems to have been limited to 282 characters, with a lifetime of perhaps 48 hours or less.
The argument that rises to the top is rarely the intellectually most valuable one, not that it would live on for more than a day or two anyway. Instead it's just the best punch line, one-uppance, or outrage fodder de jour.
Ironically, the best example of this deevolution IMO was Kara Swisher's interview of Twitter CEO Jack Dorsey, which was just a train wreck no one could follow .
Of course not having a breaking change is preferable, but that isn't always realistic.
Jokes aside, my uninformed opinion on how it could have been a better breaking change would have been to have the python3 able to understand properly python2. So that everyone could start using the same updated interpreter by setting appropriate flags or with thin wrappers. This way people could have moved to py3 and still run isolated bubbles of python 2.
Instead they caused a huge rift in the Python community and 10+ years of continued pain for what? Improved unicode support and removing the ability to type "print x"?
You claim there are language features to remove, if true you are correct they should have done that. That said in my experience most outsiders claiming some "rarely used" feature is the cause of some slowness don't have data to back their claims up. Often the feature is in fact used by some important subset. Often the feature isn't the cause of any slowdown.
Improved unicode support is a very good thing to have. Maybe you don't have to support users outside of Western Europe and the Americas where ascii works well enough. (this also excludes various native languages in the Americas and assumes the non-English marks on various letters can be ignored) Anyone who can't do that is glad to not have to fight Unicode in python.
"print x" is a minor thing, but it makes the language better for the stated goals.
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.
The on-going Python3 transition is why I decided to make the leap to either the Java or C# space. I chose C# since I'm as interested in applications (a core C# strength IMHO) as I am backend (Java dominated, but .Net is also here).
Given the technical limitations of CPython, breaking changes and general lack of wholistic support that you see from the vendors supporting Java and .Net, I am now a very happy .Net developer. Otherwise, I really loved Python. I just wouldn't use it to build anything, C# for me and Java is a fine alternative. I don't understand the hate for either, they seem industrial strength and work well for me. I can also find a job doing either of those anywhere in the country or world. Python is big, but not that big.
Guido can be thanked for forcing me to review what was truly in my best interest as I moved my career forward.
You could've said much the same thing of Usenet too. GvR didn't seem to have any trouble with Usenet back then, but 30 years later, at age 63, apparently now Twitter is the ne plus ultra of toxicity (which will amuse everyone who remembers Usenet). Maybe GvR has just gotten old, and it's not Twitter at all.
Usenet 30 years ago was a lot easier to deal with than Usenet 20 years ago. In 1996 I savored the handful of c.l.py posts per day. By 2002 I was overwhelmed, and that was after most development messages switched over to python-dev.
You weren't serious, "like, ever" is obvious false. Of course there are good things.
For me: Tech support both ways, job offers, knowledge of latest releases and new developments in my area of expertise. It's awesome.
It's not easy to take all the hate and ill-will day in day out. It's not even easy to ignore it, much less to deal with it.
I respect Guido's decision even though I was quite sad to see him step down. It's not difficult to see that, with Pythons growing popularity, things would probably have become even worse for him in the future.
Even completely harmful promotion can snowball into supporting harmful behaviour. CTO or senior developer in a small company may feel the need to promote stuff they do by writing technical articles and commenting ongoing debates in the social media. Attaching comments to anything that is trending is important if you want to promote stuff. Suddenly the person is committed with his own name to something he did not thing trough and unintentionally adding side support to some hate campaign.
There was a really good Keynote by Brett Cannon last year at PyCon about how hard, emotionally, maintaining OSS is: https://youtu.be/tzFWz5fiVKU?t=3259 -- Unfortunately the official post is buried after 50 minutes of lightning talks. He gets very emotional on stage. I was sitting with him before he gave this talk, it was a very hard talk for him to give, and so very important.
My own story like this: I took over maintenance of a module that had been abandoned, but after the better part of a decade I ran into a time in my life where I have little time for it. It had been languishing, but someone finally offered to help out on the maintenance. Great! I added them to the github project, they started triaging issues, and within a day this guy started spitting vitriol at the new maintainer.
I called this guy out, but he doubled down. I just locked the issue and moved on with my life. But this guy tracked me down and sent me an e-mail to my personal e-mail full of expletives. Followed quickly by an apology:
"I'm sorry, I didn't mean to send that e-mail from my work e-mail address, please don't get me fired."
Literally: No apology for being a jerk, just begging me not to share that exchange with their employer. All of the github comments he had made were removed or severely edited.
And... That person who offered to maintain that module? That was the last time they touched it.
The breaking point was PEP 572 (ie :=) which was quite controversial. The lesson here: One shouldn't attempt to reverse 25-year old design decisions, not even GvR. Python is too big now.
There was a compromise (and more congruent) alternative, reuse of the "as" keyword, that was thrown out immediately, and proponents rammed 572 thru despite significant objection. That's when things got ugly. Personally I disagreed with that decision, and tried to support the compromise design.
In the end, didn't think 572 was the end of the world (will be occasionally useful, if ugly), and tried to stay polite, but sadly many didn't. Then he accepted 572 and stepped down, as if one last poke in the eye, unfortunately.
I often have to write things like this:
m = re.match()
However, during the process Victor Stinner rewrote one large module using the new syntax as an exercise. We learned that ~95% of the time, only the simplest case was used, the form you gave above. The extra flexibility turned out not very important in real code.
We had a choice of ":=" syntax, duplicate but full functionality, and losing the BDFL, or ~95% functionality, language congruity, and keeping him. They chose the former.
Maybe Guido stepping aside will be good in the long run however, it was bound to happen eventually.
So I think (and hope) the effect of these changes will be that Guido will make more or less the same decisions as before, but both be under less stress when doing so (because he doesn't have to be the final decision maker), and no longer have to be concerned about people questioning the source of his authority.
Citation - Yesterday at Pycon during the Steering Council meeting he stated that he tendered his BDFL resignation the morning after approving that PEP
Maybe this is something you have to get used to.
Edit: I meant I don't know what he did as a bdfl day to day.
I apologize if this came off snarky - I did not mean for it to, I just wanted to emphasize Guido's contributions. (edited)
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.
Social media is a red herring here; this sort of thing has happened on all forms of social media since the dawn of computing. It used to be on mailing lists and Usenet. Now it's primarily on Twitter.
After 30 years of leading a project, anyone is going to get worn down.
For a new programmer, it can be a very discouraging experience having to debug even your first hello world program even though it perfectly matches the code in the tutorial.
The easiest things can be done by automatic translation, like 2to3.
The remaining parts get increasingly difficult, because Python 2 objects have to know how they are interpreted in Python 3, and vice versa.
A simper step would be to write an AST transformer to instrument Python 2 code and identify the non-Python 3-compatible uses of, for example, keys() and values(). That's almost as hard as writing a Python 3 implementation in Python 2, and I couldn't convince myself that it made financial sense given that it would still miss a lot of corner cases.
What you can do is use libraries like six to make code run just fine in both versions, and six-ify on a per file basis. This works pretty well.
AFAICT it allows for optional binding. I suppose it might seem like 'cargo cult' because Rust and Swift have 'if let'?