Update create_model() to support typing.Annotated as input

[wannieman98]

Change Summary

At the moment, dynamic model creation does not support taking input of typing.Annotated but instead only tuple(, ), taking in typing.Annotated allows using of complex input types for dynamic model creation. At the moment, typing.Annotated does not support construction information during runtime so we have to use a private class name to check whether the provided field_definition is a typing.Annotated. Also, I have rather decided that it is best to ignore any additional data types or metadata other than the first and second input variables because 1. first input variable is guaranteed to be a valid input type and 2. second input variable has to be related metadata of the first input variable.

Related issue number

Closes #8534

Checklist

• The pull request title is a good summary of the changes - it will be used in the changelog
• Unit tests for the changes exist
• Tests pass on CI
• Documentation reflects the changes where applicable
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @dmontagu

[codspeed-hq]

CodSpeed Performance Report

Merging #8947 will not alter performance

_{Comparing wannieman98:wanyoo/issue-8534 (9dd7a14) with main (5c8afe6)}

Summary

✅ 10 untouched benchmarks

[wannieman98]

Please Review!

Seems like I cannot add labels related to the pull request, would be great if I can get assistance adding the according label.

Thanks!

[Viicos]

Moving from #8947 (comment):

typing._AnnotatedAlias is an implementation detail, and is_annotated relies on get_origin which is the documented way of getting the unsubscripted version of the Annotated special form.

Instead, I would do something like:

        elif  _typing_extra.is_annotated(f_def):
            try:
                f_annotation = (
                    f_def.__origin__
                )  # __origin__ represents the annotation_type in Annotated[annotate_type, ...]

                f_value = f_def.__metadata__[
                    0
                ]  # Python Annotated requires at least one python variable to represent the annotation
            except ValueError as e:
                raise PydanticUserError(
                    'Field definitions should be a `typing.Annotation[type, definition]`.',
                    code='create-model-field-definitions',
                ) from e

The Python version check is not necessary, as is_annotated will safely return False if it is not an instance of Annotated. Plus people can make use of typing_extensions.Annotated (and is_annotated can handle both).

I'll note that accessing __origin__ ¹ and __metadata__ is not documented, although I don't think the implementation will change anytime.

One way of doing it would be:

f_annotation, f_value = typing_extensions.get_args(f_def)

Considering Annotated is guaranteed to have a type and at least one metadata value. In Python 3.10, I get TypeError: Annotated[...] should be used with at least two arguments (a type and an annotation). when trying to do Annotated[int], but I'm not sure this is the case on 3.8/3.9.

Footnotes

1. Not to be confused with the return value of get_origin (yeah this is weird). Annotated[int, ""].__origin__ returns int, while get_origin(Annotated[int, ""]) return the Annotated class. ↩

[wannieman98]

Moving from #8947 (comment):

typing._AnnotatedAlias is an implementation detail, and is_annotated relies on get_origin which is the documented way of getting the unsubscripted version of the Annotated special form.

Instead, I would do something like:

        elif  _typing_extra.is_annotated(f_def):
            try:
                f_annotation = (
                    f_def.__origin__
                )  # __origin__ represents the annotation_type in Annotated[annotate_type, ...]

                f_value = f_def.__metadata__[
                    0
                ]  # Python Annotated requires at least one python variable to represent the annotation
            except ValueError as e:
                raise PydanticUserError(
                    'Field definitions should be a `typing.Annotation[type, definition]`.',
                    code='create-model-field-definitions',
                ) from e

The Python version check is not necessary, as is_annotated will safely return False if it is not an instance of Annotated. Plus people can make use of typing_extensions.Annotated (and is_annotated can handle both).

I'll note that accessing __origin__ 1 and __metadata__ is not documented, although I don't think the implementation will change anytime.

One way of doing it would be:

f_annotation, f_value = typing_extensions.get_args(f_def)

Considering Annotated is guaranteed to have a type and at least one metadata value. In Python 3.10, I get TypeError: Annotated[...] should be used with at least two arguments (a type and an annotation). when trying to do Annotated[int], but I'm not sure this is the case on 3.8/3.9.

Footnotes

1. Not to be confused with the return value of get_origin (yeah this is weird). Annotated[int, ""].__origin__ returns int, while get_origin(Annotated[int, ""]) return the Annotated class. ↩

The typing.Annotated is introduced in Python 3.9 at PEP 593 and the syntax specifies it expects a valid type annotation and a metadata. That will be applicable for Python versions >= 3.9, and for Python versions < 3.9. Also, that seems to be applicable for python version 3.8 as the current typing.Annotated seems it has moved over without fundamental changes from typing_extensions.Annotated.

Thanks for pointing it out, it seems I can use the existing function for both typing_extensions.Annotated as well as typing.Annotated seems I just need version checks in testing.

[Viicos]

seems I just need version checks in testing.

You can use typing_extensions.Annotated in tests so that you can drop the version check here as well (or maybe keep a test with the Python version check and typing.Annotated to be sure that both are supported ;))

[sydney-runkle]

Requested some changes. Looking great overall!

[sydney-runkle]

@wannieman98,

If you're able to make these changes in the next few days, we can get this into the upcoming minor release! Ping me if you have any additional questions :). We really appreciate your contribution 🚀 !

[wannieman98]

@wannieman98,

If you're able to make these changes in the next few days, we can get this into the upcoming minor release! Ping me if you have any additional questions :). We really appreciate your contribution 🚀 !

Hi @sydney-runkle, sorry for the late revision, I've resolved the comments please review once more! Excited to have it part of the release!

[sydney-runkle]

These changes look great. Thanks for your awesome work on this!