I haven’t followed CPython’s core discussions much since they (sadly) moved away from python-dev, so I ran into the C-API changes that were made for 3.13a1 with little prior warning. At least the shear amount of changes leaves me baffled.
Hundreds of functions were removed, renamed, replaced with different functions. Header files were removed. Names were removed from header files. Macros were changed, even a few publicly documented ones. And the default answer to “how do I replace this usage” seems to be “we’ll try to design a blessed replacement in time”.
Victor Stinner mentioned that he’d try to make as many existing packages work again as he can, but then, what about the PyPI packages that are not visible enough to be helped? What about the packages that used to work but are no longer actively maintained? What about the repos that simply won’t work up a new release even if you send them a PR? What about the packages that cannot be tested with 3.13 for weeks, months or years, and that won’t report back issues to CPython, because they depend on other packages that fail to build? What about the cases where python devs disagree on a “good” public API, or where they disagree with users regarding the usability of a replacement?
I remember a story from a bank where I was working, where we found a piece of code that no-one understood and that looked unused. So we gave a developer the task to investigate. What he ended up doing was to comment out the code, adding the note “let’s see if someone will notice”. Well, no-one noticed it, until it was released and brought our production server down.
The situation that we ended up with in 3.13a1 seems similarly disruptive as the move from Python 2 to 3, although the pile of C-API changes back then was way, way smaller. The amount of breakage is so huge that I’m personally giving up on fixing it. I’d rather start using the internal APIs in Cython than try to make things work efficiently with the public ones again. I always argued against that approach, but I think this Python 4 moment is the time to seriously consider it. What would help from the side of CPython core would be to keep also the internal header files in C89/C99 style and avoid breakage in them during point releases. That’s probably not too much to ask. But I think CPython core should also be honest and openly call this release Python 4.