Detecting object wrappers - Graham Dumpleton

"The best example of this and the reason that wrapt was created in the first place, is to instrument existing Python code to collect metrics about its performance when run in production. Since one cannot expect a customer for an application performance monitoring (APM) service to modify their code, as well as code of the third party dependencies they may use, transparently reaching in and monkey patching code at runtime is the best one can do."

"Doing this can be fraught with danger and one has to be very cautious on how you monkey patch code and what the patches do. It is all well and good if you are doing this only for your own code and so any issues that crop up only affect yourself, but if applying such changes to a customers application code in order for them to use your service, you have to be even more careful."

"With such caution in mind, the latest version of wrapt was marked as a major version update. In general I thought the changes were good and everything should still be compatible for use cases I knew of, but you never know what strange things people do. My memory also isn't the best and I will not necessarily remember all the tricks even I have used in the past when using wrapt and how they might be affected."

Monkey patching is widely considered dangerous but remains the only practical solution for some Python tasks, especially for instrumenting runtime behavior. wrapt was created to enable transparent monkey patching to collect production performance metrics without requiring modifications to customer code or third-party dependencies. Such runtime instrumentation demands extreme caution because patches can introduce failures, and the stakes increase when changes affect customer applications. A major version bump of wrapt was applied to enforce compatibility safety, but an unpinned dependency at a major SaaS vendor caused customers to be unknowingly upgraded to the new major wrapt version.

Read at Grahamdumpleton