Deploying pydantic-docs with    Cloudflare Pages

View logs

CodSpeed Performance Report

Merging#10769 willimprove performances by 8.54%

_{Comparingfieldinfo-evaluated (076da3c) withmain (6e91707)}

Summary

⚡ 5 improvements
✅ 39 untouched benchmarks

Benchmarks breakdown

Coverage report

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

Wow@Viicos, nice work here. Didn't realize this would have that significant of an impact.

We can chat about potential other APIs for this, but we should definitely move forward with this change :).

Does this unblock the_typing_extra.py refactor PR?

This is great. I presume next we'll look at_apply_annotations, and we know there's a lot to gain there.

Another follow up - what if we returned something like this:

frompythonimportTypedDictclassTypeEvaluationResult(TypedDict):evaluated:boolresult:Anyerror:NameError|None

Or something like:

frompythonimportTypedDict,TypeAliasclassTypeEvaluationSuccess(TypedDict):evaluated:Literal[True]result:AnyclassTypeEvaluationFailure(TypedDict):evaluated:Literal[False]error:NameErrortypeTypeEvaluationResult=TypeEvaluationSuccess|TypeEvaluationFailure

Doesn't have to be either of those exactly, but I think you get the point :). Then, we could have one function and preserve relevant errors, but also intuitively handle attempted evals?

Maybe this isn't better, but I think it does help us avoid the overloads, though admittedly there's more conditional logic required after a function call, as the result can be many things.

Could even do a named tuple.

Seems like both the overload and structured return value have different drawbacks: what isresult if it failed to evaluate? How do you safely make use ofresult, even if you checked thaterror is None before ? (as type checkers will complain).

Maybe it's worth revisiting the API, if we want to make this module more stable and maybe expose it publicly, as it is used already by some other projects.

Yeah, fair point. Let's not go with the structured return.

One other idea - could we revert to that single signature idea, and manufacture aNameError ifevaluated isFalse based on the input?

You mean something likedict[str, tuple[Any, bool | NameError]] in the return type?

Or even likedict[str, tuple[Any, bool], but when the second value isfalse and we want to raise on failure, just thenraise PydanticUndefinedAnnotation(<information about the failed eval similar to what the NameError would have provided>)

but the issue is we currently raise usingPydanticUndefinedAnnotation.from_name_error so that's why we need the exception to be raised originally.

dict[str, tuple[Any, bool | NameError]] could work but just moves the burden of checking forbool (actuallyLiteral[True]) andNameError to the caller.

Going to go ahead and merge. We can cherry pick relevant stuff for the v2.10 official release (not including this).