Swiftorial Logo
Home
Swift Lessons
Tutorials
Learn More
Career
Resources

Python FAQ: Top Questions

48. What is Monkey Patching in Python? What are its pros and cons?

**Monkey patching** in Python refers to the practice of modifying a class or module at runtime. This involves changing, adding, or replacing methods, attributes, or even entire classes dynamically after they have been loaded into memory. The term "monkey patch" comes from the idea of "patching" code in a "hacked-together" or "clumsy" way, sometimes humorously referred to as "guerrilla patching" or "duck-punching."

In Python, this is possible because of its dynamic nature: classes and objects are mutable, and their definitions can be altered during execution.

How Monkey Patching Works:

Python makes it straightforward to monkey patch. You simply access the attribute you want to change (which can be a method, a variable, or even a class itself) and reassign it. 


# Original class/module
class MyClass:
    def say_hello(self):
        return "Hello!"

# Monkey patch it
def new_say_hello(self):
    return "Bonjour!"

MyClass.say_hello = new_say_hello # Reassign the method

obj = MyClass()
print(obj.say_hello()) # Output: Bonjour!

Pros of Monkey Patching:

  1. **Testing/Mocking:** A very common and legitimate use case. During testing, you might monkey patch external dependencies (e.g., database connections, API calls) to replace them with mock objects that return predictable data, allowing you to test your code in isolation without actual external calls.
  2. **Bug Fixes/Hotfixes:** In a production environment, if you discover a critical bug in a third-party library that you cannot immediately upgrade, monkey patching can provide a quick, temporary fix without modifying the library's source code.
  3. **Extending Third-Party Libraries:** Adding functionality to a library or framework where traditional inheritance is not feasible or desirable (e.g., when the class is sealed or not designed for subclassing in a particular way).
  4. **Runtime Customization:** Adapting the behavior of existing code dynamically based on runtime conditions or user configurations.
  5. **Backporting Features:** Implementing a feature that exists in a newer version of a library but you're stuck on an older version.

Cons of Monkey Patching:

  1. **Obscurity and Readability Issues:** Monkey patches are not immediately obvious when reading code. It can be very difficult to debug a program when a method behaves unexpectedly because it was secretly patched elsewhere. This makes code harder to understand and maintain.
  2. **Unintended Side Effects:** A monkey patch might unintentionally affect other parts of your application or other libraries that rely on the original behavior of the patched code, leading to subtle and hard-to-trace bugs.
  3. **Fragility / Versioning Problems:** Monkey patches are highly dependent on the internal structure and implementation details of the patched code. If the original library updates and changes its internal structure, your monkey patch can break without warning. This makes upgrades difficult.
  4. **Loss of Predictability:** The behavior of an object might change mid-execution, making it harder to reason about the program's flow.
  5. **Debugging Challenges:** Debuggers often struggle to correctly trace patched methods, as the actual code being run might be different from what's defined in the original source file.
  6. **Non-Standard Practice:** Generally considered a last resort. If there are other ways to achieve the desired behavior (inheritance, composition, decorators, configuration), they are almost always preferred.

In conclusion, while monkey patching offers powerful flexibility, it should be used with extreme caution and only when other, more conventional solutions are not viable. Its use is most defensible in controlled environments like unit testing. 


import unittest
import time
import sys

# --- Example 1: Basic Method Monkey Patching ---
print("--- Basic Method Monkey Patching ---")

class ServiceAPI:
    def fetch_data(self):
        """Simulates fetching data from a remote API."""
        print("Fetching real data from remote API...")
        time.sleep(0.5) # Simulate network latency
        return {"status": "success", "data": "Real API data"}

api = ServiceAPI()
print(f"Original API call: {api.fetch_data()}")

# Now, monkey patch the fetch_data method
def mock_fetch_data(self):
    print("Fetching MOCK data from local mock...")
    return {"status": "success", "data": "Mocked data for testing"}

print("\n--- Applying Monkey Patch ---")
ServiceAPI.fetch_data = mock_fetch_data # The monkey patch!

print(f"Patched API call: {api.fetch_data()}") # Calls the new mock_fetch_data
new_api_instance = ServiceAPI() # Even new instances will use the patched method
print(f"New instance API call: {new_api_instance.fetch_data()}")


# --- Example 2: Monkey Patching a Built-in Function/Module (Caution!) ---
print("\n--- Monkey Patching a Built-in Function (for demonstration) ---")

# DO NOT do this in production code! This is highly disruptive.
# It's primarily used in testing frameworks (like mock) which handle this carefully.

original_print = print # Store original print function

def custom_print(*args, **kwargs):
    args = tuple(f"[CUSTOM PRINT] {arg}" for arg in args)
    original_print(*args, **kwargs)

# sys.modules is where loaded modules live
# Monkey patch the built-in print function within its module
# Python 3 print is a statement, it's not directly patchable like this in global scope.
# But you can patch sys.stdout.write, or patch a function that *uses* print.

# More common: patching a function from an imported module
# import requests
# original_requests_get = requests.get
# def mock_requests_get(*args, **kwargs):
#     return "Mocked Response"
# requests.get = mock_requests_get

# For direct print override, you'd typically redirect sys.stdout
class CustomStdout:
    def write(self, s):
        original_print(f"[Redirected Output] {s}", end='') # Using original_print to avoid recursion

sys.stdout = CustomStdout()
print("This will now go through CustomStdout!")
print("Another line.")

# Restore original stdout
sys.stdout = sys.__stdout__
print("This is back to normal stdout.")


# --- Example 3: Monkey Patching in a Unit Test (Common & Accepted Use) ---
print("\n--- Monkey Patching in Unit Test (Concept) ---")

# Imagine a class that uses a remote service
class UserProfileService:
    def get_user_data(self, user_id):
        # In real life, this would make an actual network call
        print(f"Fetching user data for {user_id} from remote service...")
        return {"id": user_id, "name": "Real User", "email": f"user{user_id}@example.com"}

# Now, a test case that monkey patches UserProfileService
class TestUserProfileService(unittest.TestCase):
    # This method runs BEFORE each test method
    def setUp(self):
        print("\nSETUP: Patching UserProfileService.get_user_data...")
        # Store original method
        self.original_get_user_data = UserProfileService.get_user_data

        # Define a mock method
        def mock_get_user_data(self_instance, user_id): # self_instance is the UserProfileService instance
            print(f"MOCK: Getting mock user data for {user_id}...")
            return {"id": user_id, "name": f"Mock User {user_id}", "email": f"mock{user_id}@test.com"}

        # Apply the patch
        UserProfileService.get_user_data = mock_get_user_data

    # This method runs AFTER each test method
    def tearDown(self):
        print("TEARDOWN: Restoring original UserProfileService.get_user_data...")
        # Restore the original method to avoid affecting other tests
        UserProfileService.get_user_data = self.original_get_user_data

    def test_get_existing_user(self):
        service = UserProfileService()
        data = service.get_user_data(123)
        self.assertEqual(data["name"], "Mock User 123")
        self.assertEqual(data["email"], "mock123@test.com")
        print("Test 1 passed.")

    def test_get_non_existing_user(self):
        service = UserProfileService()
        data = service.get_user_data(456)
        self.assertEqual(data["name"], "Mock User 456")
        print("Test 2 passed.")

# Run the tests (unittest.main() would run them automatically, but we'll simulate)
print("Running unit tests (conceptually):")
test_suite = unittest.TestSuite()
test_suite.addTest(TestUserProfileService('test_get_existing_user'))
test_suite.addTest(TestUserProfileService('test_get_non_existing_user'))
runner = unittest.TextTestRunner(verbosity=0) # verbosity=0 for cleaner output in example
runner.run(test_suite)

# Verify that after tests, the original method is restored
print("\nAfter tests, calling UserProfileService again:")
service_after_test = UserProfileService()
print(f"Service call after tests: {service_after_test.get_user_data(789)}")
# This should now call the REAL (restored) method.

Explanation of the Example Code:

  • **Basic Method Monkey Patching:**
    • The `ServiceAPI` class initially has a `Workspace_data` method that simulates a real API call.
    • We then define a `mock_fetch_data` function.
    • The line `ServiceAPI.fetch_data = mock_fetch_data` is the monkey patch. It directly reassigns the method of the `ServiceAPI` class.
    • Now, any instance of `ServiceAPI` (even existing ones like `api` or newly created ones like `new_api_instance`) will execute `mock_fetch_data` when `Workspace_data()` is called, demonstrating the runtime modification.
  • **Monkey Patching a Built-in Function/Module (Caution!):**
    • This section provides a conceptual example of redirecting `sys.stdout` to a custom object. When `print()` is called, it ultimately uses `sys.stdout.write()`. By replacing `sys.stdout` with an instance of `CustomStdout`, we effectively "patch" the behavior of `print()` to add a prefix.
    • It emphasizes that directly patching built-ins or core modules is dangerous and should only be done with extreme care (e.g., using robust mocking frameworks like `unittest.mock`). The example includes restoring `sys.stdout` to its original state.
  • **Monkey Patching in a Unit Test (Common & Accepted Use):**
    • This is the most common and accepted use case for monkey patching.
    • The `UserProfileService` class simulates a component that interacts with a remote service.
    • In `TestUserProfileService`, the `setUp` method patches `UserProfileService.get_user_data` with a `mock_get_user_data`. This ensures that during the tests, the service doesn't make actual network calls, making tests faster, deterministic, and isolated.
    • The `tearDown` method is crucial: it restores the original method after each test. This prevents the patch from "leaking" and affecting other tests or subsequent parts of the application.
    • The output clearly shows "MOCK" messages during test execution and then "Real" messages after the tests complete and the patch is removed.

These examples highlight the direct impact of monkey patching on runtime behavior, showcasing its utility for testing and its potential pitfalls if not used judiciously.

←→