my first suggestion is to move remove sync endpoints in async generator into a separate PR if possible.

FYI @taxpon (2017/07) @frol (2017/07) @mbohlool (2017/07) @cbornet (2017/09) @kenjones-cisco (2017/11) @tomplus (2018/10) @arun-nalla (2019/11) @spacether (2019/11) @krjakbrjak (2023/02)

pydnatic also comes with a Mypy plugin: https://docs.pydantic.dev/latest/mypy_plugin/

have you evaluated it?

would it help in our case?

I have been testing with the mypy plugin enabled I should probably go ahead and add that configuration to the pyproject.toml, sadly it doesn't address the primary problem which is the fact that it doesn't understand the Constrained types https://docs.pydantic.dev/latest/usage/types/#constrained-types

Example: Plugin Enabled

from pydantic import BaseModel, StrictStr, conlist

class Foo(BaseModel):
    bar: conlist(int, min_items=3) = [1]

petstore_api/models/foo.py:29: error: Invalid type comment or annotation  [valid-type]
petstore_api/models/foo.py:29: note: Suggestion: use conlist[...] instead of conlist(...)

Further more comprehensive discussion here about using Annotated as well which works for all cases except nested constraints on pydantic<2 which is why we have the rather verbose and ugly if typing.TYPE_CHECKING solution.

#15464

my first suggestion is to move remove sync endpoints in async generator into a separate PR if possible.

I can do this, its included here because the interactions between the sync/async endpoints is incredibly confusing type wise, its sort of warping the intended use of async/await syntax and doesn't translate well to static typing at all.

why we have the rather verbose and ugly if typing.TYPE_CHECKING solution.

what about an option (e.g. supportMypy) to let users choose whether they need Mypy support or not ?

I would imagine some users like to have it enabled while other prefers the output without Mypy.

what about an option (e.g. supportMypy) to let users choose whether they need Mypy support or not ?

We could do that for sure, but honestly i cant really think of a time you DONT want mypy types in your project because even if you dont use mypy yourself you still get accurate autocomplete etc within your project

We can also use annotated for all cases except the nested conlist case which removes like 90% of the typechecking checks

this also modifies the asyncio generator to remove the sync calls and rely on async all the way through.

@Jay-Madden I wonder if you can file a new PR just for this change so that we can get this enhancement included in the upcoming release.

@Jay-Madden I'm also interested to have these 2 topics moving forward (removing the sync call + adding type information to the generated code) and I can dedicate some time on these tasks, is there anything I can do to help here?

I'd be happy to extract the code to remove the sync calls and make it into a dedicated PR for instance.

I'd be happy to extract the code to remove the sync calls and make it into a dedicated PR for instance.

yes, please file a PR to start with.

It's in #16601, thanks @Jay-Madden for the initial cleanup!

@multani @wing328

Apologies for letting this fall by the wayside. We took a look at the options and decided to move in a different direction towards k8s first party client-go for our stuff so this fell in priority. Hopefully the initial start is useful to whoever sees this through

I made an initial proposition in #16624 to improve all the generated types.

@Jay-Madden feel free to close this pull request if you don't intend to work on this in the future.

Closing this PR as the work has been extended by others