I still remember the sleepless nights. Hours spent staring at my screen, hunting for the magical place to insert .model_rebuild() calls that would make my Pydantic models stop throwing NameError exceptions. The documentation said to “rebuild models after all classes are defined,” but when exactly? In what order? The trial-and-error process felt like debugging quantum mechanics—every time I thought I understood the pattern, a new scenario would break everything.

If you’ve ever wrestled with Python’s forward reference resolution, you know this pain intimately. But recently, I discovered how pydantic-graph solved this problem so elegantly that it made me question everything I thought I knew about type resolution in Python.

The Classic Python Type Resolution Trap

Let’s start with a scenario that breaks most Python developers’ brains. You want to create two classes that reference each other:

1
2
3
4
5
6
7
8
9

def create_models():
    class User(BaseModel):
        posts: List['Post']  # Forward reference to Post
    
    class Post(BaseModel):  # Defined after User  
        author: User         # Works fine - User is already defined
    
    # Try to use them...
    user = User(posts=[])  # 💥 BOOM! NameError: name 'Post' is not defined

This fails because when Pydantic processes the User class, Post doesn’t exist yet. The string annotation 'Post' is just text that Python can’t resolve.

The “solution” that drove me to madness was sprinkling .model_rebuild() calls throughout my code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def create_models():
    class User(BaseModel):
        posts: List['Post'] 
    
    class Post(BaseModel):
        author: User
    
    # The ritual begins...
    User.model_rebuild()  # Here? 
    Post.model_rebuild()  # Or here?
    # Maybe both? In what order? 
    # What if I have more classes?
    # Should I rebuild after imports?
    # Inside or outside the function?

Each project became an archaeological dig through stack traces, trying to decode where exactly the type resolution was failing and when the rebuild should happen.

When String Annotations Work (And When They Don’t)

Before diving into the solution, let’s understand exactly when Python’s built-in type resolution succeeds and fails. This knowledge will illuminate why pydantic-graph’s approach is so clever.

Python’s get_type_hints() function can only resolve string annotations using specific scopes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# Global scope ✅ Always works
GlobalType = str

def outer_function():
    # Enclosing scope ❌ Lost when function returns  
    EnclosingType = int
    
    def inner_function():
        # Local scope ❌ Lost when function returns
        LocalType = float
        
        class TestClass:
            def method1(self) -> 'GlobalType':    # ✅ Found in module globals
                pass
            def method2(self) -> 'EnclosingType': # ❌ Enclosing scope is gone  
                pass
            def method3(self) -> 'LocalType':     # ❌ Local scope is gone
                pass
        
        return TestClass
    
    return inner_function()

# Later, when Pydantic introspects:
MyClass = outer_function()
get_type_hints(MyClass.method1)  # ✅ Finds GlobalType in module globals
get_type_hints(MyClass.method2)  # ❌ EnclosingType disappeared
get_type_hints(MyClass.method3)  # ❌ LocalType disappeared

The pattern is clear: only module-level globals survive long enough for later type introspection. Any types defined in local function scopes vanish when those functions return, leaving behind unresolvable string references.

This is where the pain lives. Most interesting patterns—like creating related classes within a factory function—happen in local scopes that get garbage collected before type introspection occurs.

The Runtime vs Static Type Checking Divide

Here’s where my understanding got murky for years. I assumed that if my IDE and static type checkers like mypy could resolve the types, then runtime introspection should work too. This assumption was completely wrong.

Static type checkers operate at analysis time, before your code ever runs. They parse your source code and resolve types using normal Python scoping rules:

1
2
3
4
5
6
7
8

def create_graph():
    LocalAlias = CounterState
    
    class NodeA(BaseNode):
        async def run(self, ctx) -> 'LocalAlias':  # ✅ Static analysis works fine
            return LocalAlias()
    
    return Graph(nodes=[NodeA])

Your IDE happily highlights this, mypy validates it, and everything looks perfect. The static type checker can see LocalAlias right there in the source code.

Runtime type introspection is a completely different beast. When pydantic-graph calls get_type_hints() to understand your node methods, it operates in a different execution context:

1
2
3
4
5

# This happens AFTER create_graph() has finished executing
type_hints = get_type_hints(NodeA.run)  # ❌ FAILS!
# The create_graph() function has returned
# LocalAlias is gone from memory
# get_type_hints() only sees module globals and built-ins

The local variables (LocalAlias) were garbage collected when create_graph() returned. The get_type_hints() function has no way to access them.

This is why you could have perfectly valid code that passes all static analysis but explodes at runtime during type introspection.

Enter pydantic-graph’s Elegant Solution

Instead of the rebuild-after-failure approach, pydantic-graph does something brilliantly proactive: it captures the namespace where the Graph is created and uses that context for all future type resolution.

Here’s the magic function that does it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def get_parent_namespace(frame):
    """Get the local namespace from the parent frame, skipping typing frames."""
    if frame is None:
        return None
    
    back = frame.f_back
    if back is None:
        return None
    
    # Skip through typing frames (for generic Graph[T] usage)
    if back.f_globals.get('__name__') == 'typing':
        return get_parent_namespace(back)
    
    return back.f_locals

When you create a Graph, this function captures a snapshot of all local variables at that moment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

def create_workflow():
    LocalState = CounterState  # Local alias
    
    class ProcessData(BaseNode):
        def run(self) -> 'ValidateData':  # Forward reference
            pass
    
    class ValidateData(BaseNode):
        def run(self) -> 'ProcessData':   # Circular reference
            pass
    
    # When Graph() is called, get_parent_namespace captures:
    # {
    #   'LocalState': <class 'CounterState'>,
    #   'ProcessData': <class 'ProcessData'>,
    #   'ValidateData': <class 'ValidateData'>,
    #   ... other local variables
    # }
    return Graph(nodes=[ProcessData, ValidateData])

Later, when pydantic-graph needs to resolve type hints, it provides this captured namespace:

1
2
3

# In pydantic-graph internals:
type_hints = get_type_hints(ProcessData.run, localns=captured_namespace)
# ✅ Success! 'ValidateData' resolves using the captured context

The Generic Type Complexity

The function gets more sophisticated when dealing with generic types. When you write Graph[StateT, DepsT, RunEndT], Python’s typing system adds extra frames to the call stack:

1
2
3
4

# Call stack for: Graph[CounterState, None, int](nodes=[...])
# Frame 0: Graph.__init__ (where get_parent_namespace is called)  
# Frame 1: typing._GenericAlias.__call__ (added by Python's typing system)
# Frame 2: your_function (the actual calling context we want)

The recursive call to get_parent_namespace elegantly skips through these typing frames until it finds the real calling context. This ensures that even complex generic usage captures the right namespace.

Why This Approach is Genius

Compare the old painful workflow with pydantic-graph’s seamless experience:

The old way (with manual rebuilds):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

def create_complex_workflow():
    class StepA(BaseModel):
        next_step: 'StepB'
    
    class StepB(BaseModel):
        next_step: 'StepC' 
    
    class StepC(BaseModel):
        next_step: 'StepA'
    
    # The debugging nightmare begins...
    StepA.model_rebuild()  # Maybe this order?
    StepB.model_rebuild()  
    StepC.model_rebuild()
    
    # Still failing? Try different order...
    # Or maybe rebuild them twice?
    # What if I have conditional imports?
    # Should this happen in __init__ or outside?

The pydantic-graph way:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

def create_complex_workflow():
    class StepA(BaseNode):
        def run(self) -> 'StepB': pass
    
    class StepB(BaseNode):
        def run(self) -> 'StepC': pass
    
    class StepC(BaseNode):
        def run(self) -> 'StepA': pass
    
    # ✅ Just works! No rebuilds needed.
    return Graph(nodes=[StepA, StepB, StepC])

The key insight is timing. Instead of building models immediately and failing on forward references, pydantic-graph:

1. Captures context at Graph creation time
2. Defers type resolution until all pieces are available
3. Resolves everything using the captured namespace

This eliminates the guesswork entirely. You don’t need to figure out when or where to rebuild—the library handles it automatically.

The Scope Boundary Wisdom

One thing that impressed me about this solution is what it doesn’t try to do. It doesn’t attempt to break Python’s fundamental scoping rules:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

def outer():
    EnclosingType = int
    
    def inner():
        LocalType = str
        
        class MyNode(BaseNode):
            def run(self) -> 'EnclosingType':  # ❌ Still won't work
                pass
        
        return Graph(nodes=[MyNode])
    
    return inner()

This still fails, and that’s by design. If libraries could reach into arbitrary enclosing scopes, Python code would become unpredictable chaos. No one would be able to reason about variable scope anymore.

Instead, pydantic-graph solves the 80% case: local scope circular references and forward references. This covers the vast majority of real-world patterns while preserving Python’s scoping sanity.

The Pattern It Unlocks

With namespace capture working reliably, you can now use patterns that were previously impossible:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

def create_state_machine():
    # Local type aliases for clarity
    UserState = MyUserState
    ErrorState = MyErrorState
    
    # Complex state transitions with circular references
    class Idle(BaseNode):
        def run(self) -> 'Processing | ErrorState':
            pass
    
    class Processing(BaseNode):  
        def run(self) -> 'Completed | ErrorState':
            pass
    
    class Completed(BaseNode):
        def run(self) -> UserState:
            pass
    
    class ErrorState(BaseNode):
        def run(self) -> 'Idle | End[None]':
            pass
    
    # ✅ All the forward references, circular dependencies, 
    # and local aliases just work!
    return Graph(nodes=[Idle, Processing, Completed, ErrorState])

This kind of expressive, locally-scoped design was effectively impossible with the old rebuild-based approach. The debugging overhead made it not worth the pain.

The Bigger Picture

What fascinates me most about get_parent_namespace is how it represents a fundamental shift in library design philosophy:

• Reactive approach: Build immediately → fail on missing types → ask user to rebuild manually
• Proactive approach: Capture context immediately → defer resolution → resolve automatically when ready

This pattern could be applied to many other libraries that struggle with forward references. Instead of forcing users into rebuild hell, capture the necessary context upfront and handle the complexity internally.

The function itself is only about 10 lines of code, but it solves a problem that has frustrated Python developers for years. Sometimes the most elegant solutions are the ones that work with Python’s design rather than fighting against it.

A New Mental Model

Before understanding this approach, I thought of type resolution as a binary problem: either Python can resolve your types or it can’t. The solution seemed to be making sure all types were “available” at the right time through careful ordering and rebuilds.

Now I see it differently. Type resolution is about context preservation. The question isn’t whether types are available, but whether you’ve preserved the right context for later introspection.

This mental shift changes how I design APIs. Instead of forcing users to manage complex dependencies and rebuild orders, I can capture the context they’re already working in and use that to resolve complexity automatically.

The next time you find yourself debugging type resolution issues, remember: the problem might not be the types themselves, but the context in which you’re trying to resolve them. Sometimes the most powerful solution is simply preserving the context where everything made sense in the first place.

(Written by Human, improved using AI where applicable.)