I haven't followed development of the Python language in a while but this article was featured last week [1] and it does feel like committees.

I have followed development of C++ and... yeah, committees and subcommittees.

[1] https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...

Well, in reality it’s more complicated there always were approaches through committee and approaches outside (conda being an initiative, and lately there is an explosion of tools making use of the pyproject.toml interface).

with packaging there are things the committee is good at (making sure that a change to packaging does not break packaging for certain configurations and use cases) and individual initiatives outside of the committee often had drawbacks improving packaging in some area and making it worse in others. But the “committee” then was able to take inspirations into the committee which means there is the best of both worlds.

IMHO the python PEP process is a good example of python going the middle way.

Frankly, yes, the PEP process looks great!

Well, the mypyc was not a side project originally, as mypy was conceived to be a complete programming language with optional static typing (https://www.slideshare.net/jukkaleh/mypy-pyconfi2012), but still (almost) 100 % python compatible and that variant was supposed to be transpileable into C.

I might be wrong, but I believe that Mypyc is like Nuitka in that you're still using an interpreter that will end up being your bottleneck even after compiling your code. Nuitka gives a ~4x speedup for most code, the bottleneck being the Python VM.

You might want to reach for something else if you need better performance than that.

> Imagine reading the C++wg release notes in the same mood that you would the python release notes.

Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!".

The secret of Python is it is actually a large community all learning to program together. They all discovered static typing together, they're all learning about functional techniques together (removing reduce() from core Python was a really interesting move), yada yada. It is a happy, productive and cohesive community. Probably a study in how to build a community around a programming language.

But one of the reasons I like Clojure is they don't have release notes any more, the release notes are basically "hey we're working on some libraries". They built something extremely powerful and it is done, because there isn't any more power needed in the core. If you invest in learning a tool, the tool shouldn't sprout a new handle and expect to be held differently.

My mood when reading the PEPs is of excitement.

While I'm not too keen on hardcore feature divergences, most of the new features have been really nice things to have, and which are never imposed. (E.g. the walrus operator, type hints, dataclasses, etc). I don't see the need to be so outright hostile to changes, unless they were clearly breaking features.

> "and which are never imposed"

I'm not sure about that part. Even if one personally ignores something new, someone else within the same project or a dependency will employ the new shiny, and invent one or a couple more ways of doing the same thing in a different way.

That means if it's in the language, you'll have to account for it. Not saying Python is, but given enough new features a language may become a kitchen sink of ideas over time.

--

(At the risk of contradicting myself a bit here, I actually agree with the features you mentioned here are all nice to have, and I like using them. IDK if nice to have is a high enough barrier to clear though.)

Industries change, needs change, new possibilities emerge. A language that doesn't change is probably either dead, dying, or headed for a tiny niche. Python changes a lot because lots of people use it and have needs and desires for it. Clojure is used very little, so doesn't have the same kind of demand for improvement or community to do it (I don't for a moment believe it couldn't be improved).

"A language that doesn't change is probably either dead, dying, or headed for a tiny niche"

Or complete. Eternal change is not a value in itself.

Right, but I think any language that is "complete" is either dead, dying, or headed for a tiny niche (or already in a tiny niche). Can you think of any counterexamples?

The vast majority of languages are dead, dying or headed for a tiny niche. How many languages can you name that aren't? There can only be at most 3 languages with more than 25% market share.

Even Python is likely to die; in time. Most things do. Something will have to change first, at the moment it is doing great.

You seem to be arguing against something I didn't say. All I'm saying is that change is a sign of life, and that non-change is a sign of the opposite.

Go ye unto your tool shed, examine your spanner for signs of life, and you will have the possibility of gaining enlightenment - for you are correct in your argument.

C.

C is changing (C99, C11, C17, C2x). It is also increasingly relegated to niches like embedded and systems, though there's still a lot of other use.

Web development as well, as it turns out (compile to wasm).

Nothing is ever truly complete. Especially mediums of communication and construction, such as a programming language.

Don’t lisps (or lisp-likes) push language feature creation into user space? And also with Clojure piggying on the JVM, I would be shocked if it needed continuous updates.

Heavily generalizing of course, but:

Only in so far as the user actually _can_ make those changes, if deemed necessary or elegant using macro facilities. Once something has proven itself good enough to be part of the language standard, there is nothing limiting language maintainers/creators to take it into the standard and ship with next release. So it is strictly more flexible in that way and users do not have to wait on commitees.

Python does too, to a limited extent. A good example is type annotations. You don't _have_ to use type annotations, but you can enforce it in your project by writing a typechecker or a preprocessor; and there's a subset of python that can be compiled statically.

And the Clojure example imho is a bit of a red herring, because while it allows a lot of flexibility (reader macros in Clojure are very powerful), they don't encourage ecosystem divergence, since Clojure can use JVM/Java for "Batteries" and most standard libraries. Cljs is more similar in that way, because it carries much of javascript's divergence with it.

You mean the mood to find out what breaks in every minor Python release?

I have been using Python in and out for system administration since version 1.6.

I think the reason that Python made it this far is that from the beginning it had a very well-documented and capable C interface.

From this, people started making lots of libraries that accelerated code and provided bindings to other software.

At a certain point the ecosystem reached a critical mass, and the rest is history.