News for hackers. Stuff that matters.
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by polyrand on Thursday April 15, 2021 @06:20PM (#26826879)
From a personal point of view, FastAPI and Pydantic are some of the greatest additions to the Python ecosystem lately.

Apart from that, FastAPI is currently the top 3 web framework according to the Python developer survey[0]. I think having such a breaking change is a serious issue.

[0] https://www.jetbrains.com/lp/python-developers-survey-2020/

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by darkteflon on Thursday April 15, 2021 @06:42PM (#26827101)
What do you like about FastAPI and Pydantic?
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by polyrand on Thursday April 15, 2021 @07:44PM (#26827560)
Other people have already mentioned great things about FastAPI (documentation, data validation, good performance, easy to use, etc).

There's also a lot to love about Pydantic alone. For me, the best thing about Pydantic is that I get performant, strongly validated objects. When I create Python apps, I try to make sure functions receive and return Pydantic models. That way, if the function does not fail, I'm 100% sure about the data coming in and out. It also saves me from writing many if statements.

Those Pydantic objects can also be dynamically created without losing the data validation parts. By using it, I feel very "secure" about my types and objects, but keeping the simplicity of Python for my whole app.

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by travisjungroth on Thursday April 15, 2021 @08:39PM (#26827964)
Have you written it with an ORM backed app? I’m curious if you put the business logic on the Pydantic models and keep the ORM small, or put the logic on the ORM and treat Pydantic like a serializer. Personally, I’d rather work with Pydantic models than ORM.
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by polyrand on Friday April 16, 2021 @04:17AM (#26831066)
I don’t use ORMs. For bigger apps, I use asyncpg and map the results to Pydantic objects. I write raw SQL and keep Pydantic objects as the “source of truth” throughout my app.
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by sandGorgon on Friday April 16, 2021 @01:44AM (#26829980)
there's a way to autogenerate pydantic and ORM (sqlalchemy) models from the same python dataclasses.

here's a fully functional gist - https://gist.github.com/sandys/671b8b86ba913e6436d4cb22d04b1...

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by madkat on Friday April 16, 2021 @05:26AM (#26831585)
We use SQLAlchemy as the ORM layer, but it's very small and most of the work is done with the Pydantic models. It works quite nicely, despite that we loose change tracking, but SQLAlchemy got us covered with merging models.
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by SirSourdough on Thursday April 15, 2021 @06:59PM (#26827248)
From the perspective of someone who mostly dabbles in creating APIs for my own use:

- Auto-generated docs and simple front end for your API allow you to examine and interact with your endpoints with essentially no added work or tools

- Feature rich and performant

- Tight pairing with Pydantic makes specifying and validating data models easy

Basically, FastAPI (and pydantic under the hood) just abstracts away a lot of the work you would need to do to build a relatively fully-featured API on your own, and adds quality of life features that one generally couldn’t justify building/setting up for themselves, especially for smaller projects. Plus, the docs are solid and it’s a pretty simple library to get started with. It’s very much been an “it just works” library for me in most cases.

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by qbasic_forever on Thursday April 15, 2021 @07:08PM (#26827316)
I like that FastAPI has documentation meant to be read from beginning to end. It walks you through not only the how but the why of core design decisions, and even dives into ancillary things like pydantic. This is in sharp contrast to most python packages of modest size where IMHO the bare minimum effort is put into technical docs. Usually you get something using a 10+ year old Sphinx template that hasn't changed for modern devices, and no description of usage is more than a trite paragraph (i.e. the attention span of a developer writing a docstring).
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by KptMarchewa on Friday April 16, 2021 @06:53AM (#26832255)
Agreed. This is an issue not only in Python. How many Java packages documentation is just generated Javadoc?
Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by ggregoire on Thursday April 15, 2021 @07:24PM (#26827422)
Among other things, having the query and body parameters automatically validated from the type hints defined on the endpoint and having the corresponding HTTP error and error message automatically added to the response is a huge time saving.

Also, the doc is great and the maintainers are very helpful on github.