Thanks Brett Cannon for suggesting to get Samuel Colvin (Pydantic) and me, Sebastián Ramírez (FastAPI and Typer) involved in this.
TL;DR: it seems to me PEP 649 would be incredibly important/useful for Pydantic, FastAPI, Typer, and similar tools, and their communities. ## About FastAPI, Pydantic, Typer Some of you probably don't know what these tools are, so, in short, FastAPI is a web API framework based on Pydantic. It has had massive growth and adoption, and very positive feedback. FastAPI was included for the first time in the last Python developers survey and it's already the third most used web framework, and apparently the fastest growing one: https://www.jetbrains.com/lp/python-developers-survey-2020/. It was also recently recommended by ThoughtWorks for the enterprises: https://www.thoughtworks.com/radar/languages-and-frameworks?blipid=202104087 And it's currently used in lots of organizations, some widely known, chances are your orgs already use it in some way. Pydantic, in very short, is a library that looks a lot like dataclasses (and also supports them), but it uses the same type annotations not only for type hints, but also for data validation, serialization (e.g. to JSON) and documentation (JSON Schema). The key feature of FastAPI (thanks to Pydantic) is using the same type annotations for _more_ than just type hinting: data validation, serialization, and documentation. All those features are provided by default when building an API with FastAPI and Pydantic. Typer is a library for building CLIs, based on Click, but using the same ideas from type annotations, from FastAPI and Pydantic. ## Why PEP 649 You can read Samuel's message to this mailing list here: https://mail.python.org/archives/list/python-dev@python.org/thread/7VMJWFGHVXDSRQFHMXVJKDDOVT47B54T/ And a longer discussion of how PEP 563 affects Pydantic here: https://github.com/samuelcolvin/pydantic/issues/2678 He has done most of the work to support these additional features from type annotations. So he would have the deepest insight into the tradeoffs/issues. >From my point of view, just being able to use local variables in Pydantic >models would be enough to justify PEP 649. With PEP 563, if a developer >decides to create a Pydantic model inside a function (say a factory function) >they would probably get an error. And it would probably not be obvious that >they have to declare the model in the top level of the module. The main feature of FastAPI and Pydantic is that they are very easy/intuitive to use. People from many backgrounds are now quickly and efficiently building APIs with best practices. I've read some isolated comments of people that were against type annotations in general, saying that these tools justify adopting them. And I've also seen comments from people coming from other languages and fields, and adopting Python just to be able to use these tools. Many of these developers are not Python experts, and supporting them and their intuition as much as possible when using these tools would help towards the PSF goal to: > [...] support and facilitate the growth of a diverse and international > community of Python programmers. ## Community support To avoid asking people to spam here, Samuel and I are collecting "likes" in: * This tweet: https://twitter.com/tiangolo/status/1382800928982642692 * This issue: https://github.com/samuelcolvin/pydantic/issues/2678 I just sent that tweet, I expect/hope it will collect some likes in support by the time you see it. ## Questions I'm not very familiar with the internals of Python, and I'm not sure how the new syntax for `Union`s using the vertical bar character ("pipe", "|") work. But would PEP 649 still support things like this?: def run(arg: int | str = 0): pass And would it be inspectable at runtime? ## Additional comments The original author of PEP 563 was Łukasz Langa. I was recently chatting with him about Typer and annotations. And he showed interest, support, and help. I think he probably knows the benefits of the way these libraries use type annotations and I would like/hope to read his opinion on all this. Or alternatively, any possible ideas for how to handle these things in tools like Pydantic. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/J7YKCCCV2GL7HUDKG7DX4INAT65SXYRF/ Code of Conduct: http://python.org/psf/codeofconduct/
