Note: This is the original script for my lightning talk, which I deviated from slightly because of time concerns. Links have been added for extra context.
I would like to talk about PEP-594, entitled ‘Removing dead batteries from the standard library’. The PEP proposes the removal of modules that are considered old, unused, or unneccesary to be kept in core Python. First drafted in mid 2018, it was assigned a number and listed as a PEP on the 20th of May 2019, nearly three weeks after my Python Language Summit talk entitled ‘Batteries Included, But They’re Leaking’. Despite being targeted for the first beta of 3.8, a decision on the PEP has not been made, and discussion has not been active since early June.
The primary concern raised in discussions is that removal of parts of the standard library may break downstream software. Breakage is, of course, undesirable, and it could be said that Python has a structural fear of it from the Python 3 transition. One example of this fear preventing progress is the Gilectomy, the project to remove the Global Interpreter Lock and allow better multithreading. For any significant improvement, the C API would have to change, and as a result, C extensions would have to do a significant amount of work converting their C extensions to something like CFFI. The benefits were not seen as worth the breakage, and further progress has not been made.
But, it is worth looking at the context of the software that it would break. Some of the largest use of C extensions in Python are in the data science world. Breaking them all of a sudden would of course be unacceptable, but the data science sector is also one flush with investment and developers, and it could be argued that a gradual transition to CFFI could occur before Python made breaking changes, and avoid any long-term detriment to users.
It is worth looking through this lens at PEP-594. We know it will break software, but what kind of software does PEP-594 break? From the responses and discussions, it seems that a majority of the code that would be permanently broken is code that cannot use replacements or spun-out PyPI libraries. Some educational cases are outlined, but a majority of it appears to be corporate software where the corporation itself makes it difficult to use software from the Python Package Index. I feel like this is an invalid reason to keep modules in the standard library.
Keeping these modules means that enterprise developers are pushing the maintance burden of this code onto the open source community. When Python is maintained by mostly unpaid volunteers, we should instead realise that code is a time and effort liability, and that the more of it we maintain, the more can go wrong. Instead the burden should be pushed back onto to these companies, companies that clearly have engineering capacity to build on top of these modules. The code does not disappear if it is removed from the standard library, instead it becomes something that they must inherit and maintain.
One of the modules, aiff, is an implementation of the lossless Audio Interchange File Format, first developed in 1988 for the Apple Mac. One of the requests for keeping it is from the lead technical director of Dreamworks Animation, where it is outlined that it is still commonly used in the post production film industry. One of the reasons it is apparently still used is that Apple’s Final Cut Pro software, costing five hundred dollars a seat, did not support modern alternatives, including Apple’s own ALAC format. Instead of using their clout to demand Apple or other video production software companies provide support for modern formats, they instead are relying on volunteers to provide the software which makes them millions of dollars per year.
It is our job to push back against this. We should not break our own community again, like we did with Python 3, but we should be willing to break things that make our own lives as volunteer software maintainers easier. We must, for the good of the community, be decisive in our actions.