Refactor _typing_extra module
#10725
Conversation
Deploying pydantic-docs with
|
| Latest commit: |
5a43b8d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b118d254.pydantic-docs.pages.dev |
| Branch Preview URL: | https://refactor-typing-extra.pydantic-docs.pages.dev |
CodSpeed Performance ReportMerging #10725 will not alter performanceComparing Summary
|
Coverage report
Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
279daa8 to
c68a904
Compare
c68a904 to
591dde0
Compare
591dde0 to
0faf9b6
Compare
a5ef806 to
088b5c2
Compare
pydantic/_internal/_repr.py
Outdated
There was a problem hiding this comment.
This display_as_type function needs to be refactored, as it is relatively expensive to recursively check for get_origin, get_args, etc. It is currently used:
- In
FieldInfo.__repr_args__, to make a string representation of theannotationattribute. This can be kept. - In
get_type_ref, called for each arg of a parametrized type. We should find a simpler way to generate a core schema reference.
088b5c2 to
291dd9b
Compare
|
Should we be concerned about some of the minor performance regressions we see for schema building here? https://codspeed.io/pydantic/pydantic/branches/refactor-typing-extra |
My assumption is that the small regression comes from the fact that in hot functions ( I think the real problem is that we should find a way to avoid calling these functions so many times, this is what I'm working on currently as part of #10297 |
There was a problem hiding this comment.
Wow, nice work @Viicos. Things feel much cleaner in the internal type management department with this PR. Left some general feedback 👍
| @@ -184,7 +184,7 @@ def _get_caller_frame_info(depth: int = 2) -> tuple[str | None, bool]: | |||
| DictValues: type[Any] = {}.values().__class__ | |||
|
|
|||
|
|
|||
| def iter_contained_typevars(v: Any) -> Iterator[TypeVarType]: | |||
| def iter_contained_typevars(v: Any) -> Iterator[TypeVar]: | |||
There was a problem hiding this comment.
Could you explain this change, briefly? Thanks!
There was a problem hiding this comment.
TypeVarType was defined as an alias to Any as a workaround, because mypy could not understand something like this:
TypeVarType: TypeAlias = TypeVarBut for pyright (and maybe mypy as of today), it is perfectly fine to use TypeVar as type annotations, it behaves as any other type
There was a problem hiding this comment.
Nice, thanks for incorporating the feedback.
Happy to merge this now, given that we're going to see perf improvements bounce back up with #10769
Change Summary
_typing_extramodule to:some_obj is typing(_extensions).SomeTypewhich can break at any time iftyping_extensionsbackports some changes from Python, in which casetyping.SomeType is not typing_extensions.SomeType.is_*functions (e.g.is_newtype,is_classvar).is_classvar_annotationfunction, that should be used in most cases. This function handlesClassVarbeing wrapped inAnnotated, and also stringified annotations.all_literal_valuestoliteral_values, replacing the unusedliteral_valuesfunction. When we drop support for Python 3.8, replace usage with a plainget_args.is_dataclassfunction,dataclasses.is_dataclassprovides a type guard return annotation.Related issue number
Checklist