Just another BDFL, that's it.
I think a lesson to take from this is that the concept of a "BDFL" doesn't really stand up. Putting an individual in charge dramatically increases the chances that they will suffer some kind of burn out compared to a situation where there are more people to share the burden with. That means the "For Life" part is more like "until they decide it's not worth the grief".
It's also clear that the "Dictator" part isn't really true; the stated reason for Guido leaving the project was the difficulty he had in getting the wider community to agree to a change he was in favour of.
The idea that having a single individual in charge produces a consistency of design seems false over the long term. Each time you burn through one leader you have to pick a new one who might have a relatively different aesthetic sense or set of priorities. And individuals change. Someone who was indifferent to functional programming, for example, in 1995 could be a huge advocate of it 20 years later, making quite different design decisions as a result.
Instead I would strongly encourage the Python community to look at what the Rust community have been doing. Leadership there is group-based, and the core team sets out an explicit vision for the project each year. This allows feedback from the community on direction and enables changes to be assessed against the explicit shared vision (vs assuming that vision exists in someone's head in the BDFL model). Ther exists a process for making changes that ensures that all (unique) feedback is considered before making a change, so that when decisions are made they're made based on shared facts. There is also emphasis on growing contributers into leadership positions, which togther with the team-based approach provides continuity when people move on from the project.
I'm not claiming it's a perfect system, but it seems to be working relatively well in a language that is going through a much more active phase (in terms of adding features) than Python.
That is what “for life” means lots of the time outside of BDFL, too.
Federal judges retire, too. Monarchs and even regular, non-benevolent dictators abdicate or otherwise step down.
Happy to talk more with anyone who's interested in this topic. :)
I would accept a PCOE with lifetime appointments and confirmation by core contributors but turning it to a full democracy seems likely to change the things I love most about the language
1. elect anyone as BDFL
2. new BDFL announces they will pass a few PEP Guido was adamant against, because, well, now they are the BDFL
3. Guido realizes the mistake and we have the good old BDFL a while longer
Guido was good. If he hadn't been good, Python wouldn't have caught on like it did. If someone who starts a small project turns out to be bad at it, that's no great loss - there are a lot of small projects. You don't see the ones that fail.
But if you put someone in charge of a large project and they mess it up, that's a large problem. It's better to go for a safe option with a reasonable expected value than for the option with the highest best-case value.
Hopefully Python continues to be guided in this manner, and Guido can help rally the Python community around a successor.
> There should be one-- and preferably only one --obvious way to do it
There are already 20 different ways of solving any given problem or of coding any given solution. At least if a single paradigm is used, then those familiar with it are unlikely to run into big surprises about how things are implemented. If your developers are used to an imperative style, a chunk of code in the middle of the codebase written in a strongly functional style is very difficult to comprehend.
In one tool I wrote for work, I use function application to progressively transform a stream of events. It's a beautiful, neat solution to the problem, but confuses the hell out of everyone else because they've never written any Haskell. There are other ways to implement this that are just as clear and abstracted and maybe they take slightly more code, but it is code that is more maintainable by everyone else. Good code to me is not that which looks like it was coded by a genius, but that which looks like any child could have written it. For some code this is very hard, but I find it easier in Python than other languages.
The more 'choices' that you have, the more inconsistency there will be about who chooses what. There is obviously a tradeoff here with giving developers the right tools for the job, but list comprehensions are a great example of how you can do that without having to use a different paradigm.
And then it offers 20 equally good ways: generators vs comprehensions vs iterators vs foreach loops vs map and filter, async vs threadpools vs processpools, and so on.
>> There should be one-- and preferably only one --obvious way to do it
Unfortunately this was true ten years ago. Now, python is just following C++ and become this behemoth of features, especially with recent PEPs, which aim at saving one or two lines of code.
People feel the need for example for anonymous functions that support statements but Python’s lambdas only support expressions and it turns out there’s not much you can do with those in Python. It’s the reason for why over the years Python acquired features for use cases that can normally be solved via higher order functions in other languages like Ruby.
I think it is time to accept Python for what it is. A dirty, mutable language that gets the job done in certain contexts. Trying to change it I think does more harm than good.
That you need some local state to implement a pure function isn't a problem as you can limit it to very simple things. Anonymous functions are not something you need either, just give it a name and pass it, wtp?
I agree most of the "Python is not functional enough" criticism comes from people who just want as pure FP as possible.
I don't even like the new assignment PEP because it just adds more complexity and more ways of doing the same thing. And knowing that it was the straw that broke the camel's back and pushed Guido away, makes me like it even less.
I don't think this is how open source development works. Probably most of the core contributors are doing it for pleasure, not for satisfying the needs of the users.
Then there is the implication that because they are doing it for pleasure, they don't owe anything to anyone. It's ridculous. This software affects millions of people and it's not a dumb hobby project.
How do you take that assertion and turn it into something actionable?
What, concretely, would they be doing differently if they fully signed on to the above?
