[HN Gopher] PEP 563, PEP 649 and the future of pydantic and FastAPI
___________________________________________________________________
PEP 563, PEP 649 and the future of pydantic and FastAPI
Author : amrrs
Score : 65 points
Date : 2021-04-15 21:10 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| josalhor wrote:
| I have developed a quite powerful tool building on top of Python
| type hints. In a way, I have almost started loving their
| flexibility as an API designer.
|
| I hope PEP 649 or a similar proposal is approved before 3.10.
| dec0dedab0de wrote:
| I've read all the arguments about static typing, but I still
| can't comprehend how people get themselves into a situation where
| using the wrong type is a problem. I totally understand it as an
| optimization if your language supports it, and even for
| generating docs. I just don't know why people insist on writing
| code to stop themselves and other developers from doing things.
|
| That said, I really really can't stand breaking backwards
| compatibility, and it sounds like that is what is happening here.
| progval wrote:
| > I just don't know why people insist on writing code to stop
| themselves and other developers from doing things.
|
| In the hope of stopping yourself from doing the _wrong_ things
| more often than the right things.
|
| It also forces some of the documentation (the signature) to be
| up to date.
| vore wrote:
| In a larger codebase, there's two major kinds of value you can
| get out of types:
|
| - Types act as a contract between component surfaces - if you
| need to integrate multiple components and have different people
| working on it, having the compiler enforce the contract is
| super useful.
|
| - Types act as a refactoring aid - if you need to alter a
| component, the compiler can assist you in telling you what
| needs to be changed and you can offload more of that work at
| compile time rather than at run time.
|
| As pieces move and change, tracking down what else needs to get
| moved and changed gets more and more difficult and this is
| where the "passing the wrong type in" issue can occur: having
| the compiler help you out with that is a huge boon.
| nuclear_eclipse wrote:
| The big benefit of type hints things like Pydantic (and some
| things I've written myself) is that it can provide useful
| runtime information. If you know that property `obj.foo` is
| hinted with `List[Foo]`, then that allows you to do something
| expecting to have a list of `Foo` objects. This is really
| extraordinary for deserializing untyped data (like a json blob)
| into appropriate objects at runtime. You can take something
| like `{"foo": [...]}` and attempt to deserialize each element
| of the `foo` list into `Foo` objects, rather than just guessing
| at what the list contains. If you stop being able to understand
| type hints at runtime, then the only thing they're good for is
| documentation and static analysis.
| nojito wrote:
| Algebraic errors are impossible with types and happen all the
| time in dynamic languages.
| SomaticPirate wrote:
| I don't use Python nearly as much as I used to (mostly Go now)
| but changes like this make me realize how much I appreciate the
| Go 1 compatibility guarantee. I have Go libraries from 1.6 that I
| have upgraded without a second thought.
|
| These sort of PEPs (remember the walrus operator?) seem like
| fundamental language changes that serve to divide the community
| without much gained.
|
| Although I will say, Go has made it much easier to be involved in
| the language design process.
| qbasic_forever wrote:
| Nothing is immune, these are fundamentally people and person
| problems which can and will affect any language. It's ironic
| that just this week one of the core maintainers of Perl stepped
| down because of backlash and harassment from other maintainers
| over proposed changes
| (https://news.ycombinator.com/item?id=26779152).
|
| Python is a little younger than Perl but also faced similar
| problems--Guido had so much backlash against proposals that he
| stepped down too
| (https://news.ycombinator.com/item?id=17515492).
|
| Go is younger than either of those but not immune to the same
| fate--just look at the total divide and amount of controversy
| created over things like generics or modules in the community.
|
| There's no magic fix for this--if an organization is going to
| thrive and grow (or even just survive) for 30+ years it has to
| address those issues sooner rather than later. Burnout, at all
| levels, is real.
| ben509 wrote:
| I had tried to make json-syntax work with __annotations__, glad
| to know it's not just me having trouble with it.
| polyrand wrote:
| 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/
| darkteflon wrote:
| What do you like about FastAPI and Pydantic?
| SirSourdough wrote:
| 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
|
| - 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 a
| 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.
| guiscaranse wrote:
| It makes no sense for me how some of the people on the mail list
| threats PEP 649 as some sort of PEP 563 killer while it clearly
| states as an alternative to it. I really don't care if they keep
| 563 as long as 649 (or some alternative) exists. Limiting what a
| developer can do with the language just because you don't like
| type hints/annotations makes 0 sense and so far I haven't seen
| one single valid argument to keep 563 the way that it is other
| than that it "was already available on 3.10 Alpha"
| s_Hogg wrote:
| I read that and I'm still no clearer about how to do anything
| about this, though as a user of both pydantic and fastapi (and
| having mandated their adoption in my org), I'm extremely
| motivated to do something about this. Can anyone spell out to me
| precisely what i need to do to be heard?
| SomaticPirate wrote:
| I think +1 on this post would be a good first step
| https://mail.python.org/archives/list/python-dev@python.org/...
___________________________________________________________________
(page generated 2021-04-15 23:00 UTC)