CodSpeed Performance Report

Merging#10380 willnot alter performance

_{Comparingkc0506:fix-10150 (b42288d) withmain (07beaff)}

Summary

✅ 49 untouched benchmarks

Coverage report

This PR does not seem to contain any modification to coverable code.

@sydney-runkle I think the nested scope issues here are different from the case ofTypeAdapter .
Take this code for example:

from __future__importannotationsclassA[T:int](BaseModel):defg1(self):returnTypeAdapter(list[T])defg2(self):@validate_calldeff()->T: ...

When callingTypeAdapter, the Python bytecode actuallyuseT, soT will be recognized inside the closure when compilingg1's code object. ThusT will becopied into locals at runtime wheng1 is called.

On the other hand, theT insideg2 is just purestr, not a reference toT, so from the viewpoint of compiler,T is not evenused byg2. Therefore at runtime, the local namespace ofg2 will not containT, which means there is no way to accessT inside@validate_call.

So currently I guess the best we could do is to make sure things work withoutfrom __future__ import annotations, and perhaps note the issue somewhere of the docs. I hope this make sense for you.

Gotcha.

My suggestion was that we could add a_parent_depth argument tovalidate_call to control how deep we look in theparent_frame_namespace, which might resolve the original issue you mentioned. Maybe not though, I haven't tried locally.

importinspectimportsysfrompydantic._internalimport_typing_extra# analogy to `validate_call`, we want to access `a` in this functiondefapi():# ! `f` is NOT in stack# print([f.function for f in inspect.stack()])  # ['api', 'g', '<module>']# print(sys._getframe(1).f_code.co_name)  # 'g'# print(sys._getframe(2).f_code.co_name)  # '<module>'# parent_depth should add 1 because `parent_frame_namespace` is pushed to call stackprint('ns of g:',_typing_extra.parent_frame_namespace(parent_depth=2))deff():a=1defg1():api()defg2():aapi()returng1,g2g1,g2=f()g1()# ns of g: {}g2()# ns of g: {'a': 1}

Here is a simple demo. My point is that by the timeapi is called,f is not in the stack anymore. So we can not finda in the namespace no matter how deep we look in parent frames, unless it is caught by closure, as the case ofg2. This behavior should be the same forclass definition.