Here is some code I am going to merge soon into a widely used open source project, relied on by many very large corporations:
```
def noop():
pass
import threading
threading._after_fork.__code__ = noop.__code__
```
Some interesting things about this:
1. Just in case you don't understand what this is doing (this is a good thing, you're better off not knowing): this is a terrible terrible crime against abstraction. I am changing the code of a function so the function does nothing when called.
2. I doubt any LLM coding tool would generate this code without a human doing all of the heavy lifting to figure out why _this_ is the fix, however hideous. That's good! You really don't _want_ code like that.
3. Except that sometimes you _need_ code like this. Due to technical decisions made 20 years ago (monkeypatching the Python stdlib to implement green threads), compounded by many bad decisions made hither and yon for decades (fork() without execve() is the worst - https://pythonspeed.com/articles/python-multiprocessing/), this is the most straightforward way to proceed.
4. Which is to say, part of being an good engineer is knowing when the rules need to be broken. In this case, it's what I've dubbed "transgressive programming", a thing you really don't want to do... except when you have to. https://pythonspeed.com/articles/transgressive-programming/
This is, thankfully, a stop gap as we work towards sunsetting the project; we already have an off-ramp, but there's still a large userbase that depends on it. So for now bugs need to be fixed, one way or another.
And if your organization needs some help with open source maintenance, I might have a little free time in my consulting schedule. In addition to helping migration off projects, I've also revived a project, which is now happily puttering along without my help, and more broadly done decades of maintenance.
#python