[moezd]

This feels too much like breaking the guarantee sticker of a vendor code, and if your vendor pushes updates weekly, or daily, you are stuck pushing updates to your shimmed code, which officially becomes "unnamed fork". Even for tests, let's say that they changed an input type, I don't see an improvement in my workflow: I still need to update my "unnamed fork". At least with a fork I get to see the whole git history, including my contributions, and testing with monkey patching helps me create clear setUp and tearDown steps.

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

[ramses0]

Yeah, but the example of "*.retries(...)", in the context of "import some_login_library.Login(...)" is quite powerful! It basically looks like a "super-decorator", and I can definitely see the utility of effectively re-compiling a (third-party) module at runtime to handle something that's more unique to your use case.

Your patch "with retries" might never be accepted, and maintaining any kind of fork(s) or "out-of-tree patches" is not as integrated into the programming environment. Being able to say "assert WrappedLoginLibrary().login(), '...with retries...'" keeps you testable and "in" the language proper.