Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Kragen Javier Sitaker Newsgroups: comp.lang.misc Subject: Python deliberately breaking backward compatibility (was Re: =?utf-8?Q?What=E2=80=99s?= Your Least Favourite Programming Language?) Date: Fri, 28 Aug 2026 21:03:13 -0300 Organization: Primarily biological and memetic Lines: 90 Message-ID: <87fqzxbxoe.fsf_-_@debian> References: <10e1m38$8ukd$1@dont-email.me> <20251031081742.00003c76@gmail.com> <87ik4vdrxw.fsf@debian> <116r3k4$218ss$5@dont-email.me> <871pbido8z.fsf_-_@debian> <116t2ic$2ok8c$4@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 29 Aug 2026 00:05:31 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2967198"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+5YT/NKk71Wlua1KcFp25/"; posting-host="19c753fba95970cf1a99e4804f17687c" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:try3McejK7CoRH+JmAbiF6ZTU9o= sha1:RaoiDaEKdO06uT32a1VhvJhq1G4= sha256:2IWQ74YOU6cHxqHGSZxJc+fr5hK16x6Uc5Gn/eo+cK8= sha1:1XJrzf2/pfGIIIO8b5wvbUe4+4c= sha256:z2poJe5wo/3I29/j3cFYX3HUoCB7OnQrftvh76MIqVA= Xref: csiph.com comp.lang.misc:11850 Lawrence D’Oliveiro writes: >>> On Thu, 27 Aug 2026 21:11:55 -0300, Kragen Javier Sitaker wrote: >>>> the Python maintainers have adopted a policy of deliberately >>>> breaking standard library backward compatibility in every point >>>> release. >>> >>> In what way? >> >> They call it “removing dead batteries from the standard library” ... > > So they don’t want to keep accumulating legacy baggage that just adds > to the ongoing support burden. Yes, that is their motivation for adopting the policy of deliberately breaking standard library backward compatibility in every point release. However, their motivation, understandable though it is, is irrelevant to my point, which is that as a result of this policy, Python has, in practice, gone from being one of the *most* portable languages to one of the *least*; you can’t even reliably run a Python application you wrote on Ubuntu 25.10 (Python 3.13) on Ubuntu 26.04 (Python 3.14). In Python 3.14, the list of things removed to deliberately break backwards compatibility in it is relatively small; it includes ast.Num, asyncio.FastChildWatcher, pickling itertools iterators, `pty.master_open()`, and sqlite3.version. And they’re changing the default start method of `multiprocessing` from `fork()`, which usually won’t crash people’s code but will introduce massive performance regressions in some cases. > Every open-source project does that. The key is to support the > important stuff that people care about. In some sense, this is obviously true, but there are enormous differences of degree. The current Python policy is way down at the gratuitous-instability end of the spectrum. JavaScript, by contrast, still supports `with`, and glibc still supports `gets`. > Does anybody still want to use the “cgi” module? Yes. Although CGI was pretty costly when it went out of style in the 01990s, hardware has improved dramatically, and CGI can now handle half a billion hits per second on one server which is enough for all but the biggest public websites. CGI is a relatively low-tech, simple interface that is extremely widely supported by web servers. For cases where the Python startup overhead is killing you, even on current hardware, you can use the `cgi` module with FastCGI . Nowadays, hardware is so fast that the CGI execution model has seen a huge resurgence, mostly using a slightly different interface from the original CGI — they call it “serverless” now. I have three or four CGI scripts written in Python that I’ve been using for many years without having to maintain them. The `cgi` module probably should not have been added to the standard library in the first place — its interface is kind of error-prone and clumsy. But, having been added, it should not have been removed. In addition to `cgi` they also removed `cgitb`, which was an invaluable aid to debugging Python programs that had nothing to do with CGI or the Web; simply by running import cgitb; cgitb.enable(format="text") at the beginning of program execution, your stack traces include the values of local variables, which is very frequently enough to make bugs trivial to track down. I assume the Python maintainers removed this functionality because they didn’t know about it. > Sun “au” file format? Yes, obviously? There are plenty of audio data files from 30 years ago in .au format. If you have an existing Python application that can read them, how is it beneficial to break it? Was there a lot of maintenance load involved due to the rapid changes in the .au file spec? Moreover, users of such an application would suffer even if they don’t have any .au files — the application will crash at startup with an ImportError, because it foolishly used the standard library support for the most popular audio file format. > A Unix password encryption library that doesn’t keep up with current > password encryption formats? This one I’m more skeptical of the importance of. But your other two examples are obviously egregiously bad. Kragen