Point being, it's a lot of really complicated fiddling with the python import system. And a lesson I have learned is that messing around with import internals in python is extremely tricky to get right. Furthermore, trying to coordinate correctly between modules that do and don't get modified my the hook is very finicky. Not to mention that supply side attacks on the import system itself could be a terrifying attack vector that would be absurdly difficult to detect.

All this to say, I'm not a big fan of monkeypatching, but I know exactly how it behaves, its edge cases, and what to expect if I do it. It is, after all, pretty standard practice to patch things during python unit tests. And even with all its warts, I would prefer patching to import fiddling any day of the week and twice on Sunday.

Feedback for the author: you need to explain the "why" of your project more thoroughly. I'm sure you had a good reason to strike out in this direction, and maybe this is a super elegant solution. But you've failed to explain to me under what circumstances I might also encounter the same problems with patching that you've encountered, in order to explain to me why the risk of an import hook is justified.

If I control all the imports I can usually subclass things myself just fine.

The README mentions 3 scenarios that this might be preferred over, but not the fourth which I regularly do: Create my own functions/classes that are composed from the unchanged modules. E.g. a request_with_retries function which adds retry logic to requests without the need to monkey patch. I regularly use decorators as well to add things like retries.

For more complex scenarios Modshim might win out, as mentioned in the understated section of the README "Benefits of this Approach":

> Internal Reference Rewriting: This example demonstrates modshim's most powerful feature. By replacing requests.sessions.Session, we automatically upgraded top-level functions like requests.get() because their internal references to Session are redirected to our new class.

> Preservation of the Original Module: The original requests package is not altered. Code in other parts of an application that imports requests directly will continue to use the original Session object without any retry logic, preventing unintended side-effects.

What I think this means is Modshim lets you really get in to the guts of a module (monkey-patch style, giving you god-like powers), while limiting the damage.

https://github.com/epgui/pybond

It's much cleaner than monkey patching, and it will more likely detect if an update conflicts with your patching.

I've used it by packaging everything through nix, but that can be cumbersome.

The big win here is that it keeps things clean and maintainable — you only ship your changes instead of managing a full fork, and you don’t mess up the global namespace. It also makes experimenting with tweaks a lot easier.

The tricky parts might be keeping import behavior consistent and making sure debugging still works nicely since AST rewriting can sometimes make stack traces a bit messy.

Overall, it’s a clever middle ground between monkey-patching and forking — really nice concept.

Edit: okay Readme is clear on it and the description does make sense, the short description here just confused me.

When you have a scalpel, you give it to operating doctors during the operation, not to 5 year olds on the street.

> * Fix bugs in third-party libraries without forking

> * Modify the behavior of existing functions

> * Add new features or options to existing classes

> * Test alternative implementations in an isolated way

only the last sounds close to something you might actually want to do, and then only as a throwaway thing

If you want to change a library, fork it. If you want to change the behavior of existing functions, don't or at least fork first. If you want to add new features to a class, write a new class, or again, at least fork first