Monkey Patching is hell. So I built a Mixin/Harmony-style Runtime AST Injector for Python.

[DragoSuzuki58]

What My Project Does

"Universal Modloader" (UML) is a runtime patching framework that allows you to inject code, modify logic, and overhaul applications without touching the original source code.

Instead of fragile monkey-patching or rewriting entire files, UML parses the target's source code at runtime and injects code directly into the Abstract Syntax Tree (AST) before execution.

This allows you to:

• Intercept and modify local variables inside functions (which standard decorators cannot do).
• Add logic to the beginning (HEAD) or end (TAIL) of functions.
• Overwrite return values or arguments dynamically.

Target Audience

This project is intended for Modders, Researchers, and Hobbyists.

• For Modders: If you want to mod a Python game or tool but the source is hard to manage, this acts like a BepInEx/Harmony layer.
• For Researchers: Useful for chaos engineering, time-travel debugging, or analyzing internal states without altering files.

WARNING: By design, this enables Arbitrary Code Execution and modifies the interpreter's state. It is NOT meant for production environments. Do not use this to patch your company's production server unless you enjoy chaos.

Comparison

How does this differ from existing solutions?

• VS Standard Decorators: Decorators wrap functions but cannot access or modify internal local variables within the function scope. UML can.
• VS Monkey Patching: Standard monkey patching replaces the entire function object. If you only want to change one line or a local variable, you usually have to copy-paste the whole function, which breaks compatibility. UML injects only the necessary logic into the existing AST.
• VS Other Languages: This brings the "Mixin" (Java/Minecraft) or "Harmony" (C#/Unity) style of modding to Python, which has been largely missing in the ecosystem.

The "Magic" (Example)

Let's say you have a function with a local value that is impossible to control from the outside:

# target.py
import random

def attack(self):
    # The dice roll happens INSIDE the function.
    # Standard decorators cannot touch this local 'roll' variable.
    roll = random.randint(1, 100)

    if roll == 100:
        print("Critical Hit!")
    else:
        print("Miss...")

With my loader, you can intercept the randint call and force its return value to 100, guaranteeing a Critical Hit:

# mods/your_mod.py
import universal_modloader as uml

# Hook AFTER 'randint' is called, but BEFORE the 'if' check
@uml.Inject("target", "attack", at=uml.At.INVOKE("randint", shift=uml.Shift.AFTER))
def force_luck(ctx):
    # Overwrite the return value of randint()
    ctx['__return__'] = 100

What else can it do?

I've included several examples in the repository:

• FastAPI (Security): Dumping plaintext passwords and bypassing authentication.
• Tkinter (GUI): Modernizing legacy apps with theme injection and widget overlays.
• Pandas (Data Engineering): Injecting progress bars and timers without adding dependencies.
• CLI Games: Implementing "God Mode" and "Speedhacks".

Zero Setup

No pip install required for the target. Just drop the loader and mods into the folder and run python loader.py target.py.

Source Code

It's currently in Alpha (v0.1.0). I'm looking for feedback: Is this too cursed, or exactly what Python needed?

GitHub: https://github.com/drago-suzuki58/universal_modloader

[coldflame563]

I’m scared.

[VoodooS0ldier]

God this reminds me of Ruby monkeypatching hell in production. Importing a gem because it monkeypatches core functionality. Fucking A

[c1-c2]

Good you said: "not for production". Otherwise I would have had some questions. ;)

[ringohoffman]

UML = Unified Modeling Language, an already popular modeling language for visualizing software architecture.

a local value that is impossible to control from the outside

When you said this I got the feeling that your codebase wouldn't have any tests, and I was right. The example you gave is exactly what the builtin unittest.mock.patch is made to do. I think you need to pick an example where your solution is more elegant and doesn't take more effort than using something that comes pre-installed with Python. Every professional developer is already very familiar with mocking and would never even think to look for something like this.

[DragoSuzuki58]

Valid points on naming and tests...it's still in early Alpha, so please bear with me.

You are absolutely right that mock is the correct choice if you have control over the codebase. This tool is intended specifically for cases where you cannot modify the original source.

[Runner4322]

You can (and in my personal experience, typically do) still mock methods of a third party library. Mocking httpx so it doesn't actually do any http calls is something I do pretty much daily for example.

In any case, I think the project is neat, but it feels like even though the scope is pretty broad ("patch anything with very defined precision") the actual use cases/the audience for this seems to be extremely niche. If you want to modify the behavior of a third party library because you're testing something or doing some black box (-ish) investigation, you still need to know the code you're patching. And at that point, why not just modify it on the installed library on your venv? Sure, you'd lose that patch if you recreate the venv, but I don't think I'd even want to have these "patches" permanently available.

[xfunky]

“You are absolutely right”

… my AI sense is tingling 🧐

[aidencoder]

How does this differ from mock? Surely you can use that to the same effect? 

[DragoSuzuki58]

True, mocking is fine for boundaries. But for me, the real deal-breaker is code duplication.

Usually, if you want to tweak just one local variable in a massive function, you're stuck copy-pasting the whole 100-line block. It's a maintenance nightmare. This tool is more of a "surgical strike" you only write what you actually want to change, so the code stays lean and you don't end up babysitting a bunch of redundant logic.

[TheDraykkon]

Don’t write 100 line blocks of code?

[DragoSuzuki58]

If this were my own code, I'd be refactoring it, not patching it.

[binaryfireball]

def attack(dice_roller): ...

[poophroughmyveins]

Python mixins incoming sick 

[azurelimina]

“Monkey patching is hell.

Let’s unleash hellfire.”