IMHO, working on a programming language is only for some, just like working on a database is only for some. The first rule should be: "you should never break the language, ever". Just like you should never break the database or kernel behavior.

This is why I like to stick to C, Common Lisp, Clojure, and (to some extent) Java/JVM. I don't know about Clojure's future, but C and Common Lisp have been fine for the last 40 years, and I'm not expecting the least in the upcoming years.

I half agree with this rule. I think that it's fine to break things as long as you make a semantic version change _and_ provide automated tooling for upgrading old code. If you can't build this tool, that is a strong negative signal for both versions of the language.

What I don't like about say, c, is that it has various backward compatible additive dialects like c11 vs c99. I personally don't agree that c11 and c99 are the same language in spite of the backwards compatibility and I think it makes the entire ecosystem worse. At some point there needs to be a successor rather than just piling on to old broken designs. I would prefer a better FFI or other tools to interface with legacy code in the new dialect.

> I half agree with this rule. I think that it's OK to break things as long as you make a semantic version change _and_ provide automated tooling for upgrading old code. If you can't build this tool, that is a strong negative signal for both versions of the language.

I'd be happy to find automated tooling for upgrading old code that actually works. Python 2to3 converter worked on simple code but would fail on anything mildly complex (what would that tell about the Python language then :P).

IMHO, breaking language could makes sense if you have built-in runtime (like golang) or you ship native binaries that depend solely on kernel or libc (C/C++). You build your program and ship it to the clients. But, when you have a runtime like Python, you must also force clients to upgrade it. And the problem with Python is that you can't easily do that because system stuff usually depends on a particular version (yum/dnf, ubuntu services, and so on). And, unlike Java, the Python community only advertises a little about having multiple Python versions installed simultaneously.

> What I don't like about say, c, is that it has various backward compatible additive dialects like c11 vs c99. ... At some point there needs to be a successor rather than just piling on to old broken designs.

This is why people are still using C. There are many successors with varying success (D, C++, Rust, Zig...) and much more added complexity to the language and runtime. Language simplicity, compilation speed, and compiler simplicity - all of that was lost.

Python breaks compatibility across minor versions. I'm not surprised seeing such proposal.

do you have examples?

One painful one that is still reverberating a bit in some areas is the renaming of "SafeConfigParser" to just "ConfigParser" in the standard library (in 3.12). This caused a whole lot of breaking in some areas because versioneer (a package for determining a package version from git tags) used it (in code that was placed inside your package, and so couldn't be solved by just upgrading versioneer).

Also, I'm starting to get warning about something in tarfile that I will need to track down: https://peps.python.org/pep-0706/

There's many, but here's just one.

    Python 3.7.9 (default, Aug 23 2020, 00:57:53)
    [Clang 10.0.1 ] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import cgi
    >>>

    Python 3.13.0 (main, Oct  8 2024, 01:04:00) [Clang 18.1.8 ] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import cgi
    Traceback (most recent call last):
      File "<python-input-0>", line 1, in <module>
        import cgi
    ModuleNotFoundError: No module named 'cgi'

I think distutils is a good example of that (though imo it's a justified break, but still)