Introduction

Monkey patching means changing code behavior at runtime by replacing or adding functions, methods, or attributes on an existing object, class, or module. It is powerful because it lets you alter behavior without editing the original source, but that same power makes it easy to create confusing or fragile systems.

A Simple Example

In Python, monkey patching often means replacing a method after import time.

1class Greeter:
2    def hello(self):
3        return "hello"
4
5
6def patched_hello(self):
7    return "patched hello"
8
9Greeter.hello = patched_hello
10
11print(Greeter().hello())

After the assignment, every new Greeter instance uses the patched method.

That is monkey patching: runtime modification of behavior that the original class definition did not declare.

Why People Use It

Common reasons include:

• fixing a bug in third-party code temporarily
• adapting a library in tests
• adding instrumentation or logging
• changing framework behavior when extension hooks are missing

Sometimes it is the fastest workable option, especially in dynamic languages. That is why the technique keeps showing up even though many developers dislike it.

Why It Is Risky

The main problem is hidden behavior change. Someone reading the original class or module source may not realize the running program behaves differently.

That creates problems such as:

• harder debugging
• surprising interactions after library upgrades
• test behavior that differs from production behavior
• patches applied in one import path but not another

So monkey patching is less about whether it can work and more about whether the maintenance cost is worth it.

JavaScript Has the Same Pattern

JavaScript allows similar runtime modification:

1class Greeter {
2  hello() {
3    return "hello";
4  }
5}
6
7Greeter.prototype.hello = function () {
8  return "patched hello";
9};
10
11console.log(new Greeter().hello());

This is one reason the technique is often discussed in dynamic-language ecosystems such as Python, Ruby, and JavaScript.

Prefer Explicit Extension Points When Possible

Before monkey patching, look for safer alternatives:

• subclassing
• dependency injection
• wrappers or decorators
• official plugin or middleware hooks
• test doubles or mocks

Those approaches make behavior changes easier to find and reason about.

Monkey patching becomes more defensible when you genuinely have no good extension point and the patch is tightly scoped and well documented.

Good Hygiene If You Must Do It

If a patch is unavoidable, reduce the blast radius:

• apply it in one known place
• document why it exists
• keep the replacement small
• cover it with tests
• remove it once the underlying library is fixed

That turns a dangerous trick into a controlled workaround.

Testing frameworks sometimes use controlled monkey patching to replace time, networking, or external side effects. That is safer than ad hoc production patching because the scope is narrow, the lifetime is short, and the test harness can restore the original behavior afterward.

Common Pitfalls

• Applying a patch globally without realizing how many call sites it affects.
• Forgetting that a library upgrade may break the patched assumption.
• Using monkey patching where composition or dependency injection would be clearer.
• Hiding important application behavior in startup side effects that readers never notice.
• Letting a temporary patch become permanent infrastructure.

Summary

• Monkey patching means changing existing behavior at runtime.
• It is common in dynamic languages such as Python and JavaScript.
• The main advantage is flexibility when no clean extension point exists.
• The main cost is hidden behavior and higher maintenance risk.
• Use it sparingly, document it clearly, and prefer explicit alternatives when they exist.