Update 2: see https://github.com/samuelcolvin/pydantic/issues/2678#issuecomment-1008139014, for a summary of how PEP 563 could effect pydantic.
Update: see below this has been resolved by a changes in python 3.10 from the python steering council.
Thanks everyone for your thoughts, patience and hard work.
PEP 563 "Postponed Evaluation of Annotations" was introduced in python 3.7 behind the from __future__ import annotations
switch, it basically meant all annotations are strings, not python objects.
Pydantic has tried to supported Postponed Annotations since v0.18.0
, see #348.
The problem however is that trying to evaluate those strings to get the real annotation objects is really hard, perhaps impossible to always do correctly, see #248 #234 #397 #415 #486 #531 #545 #635 #655 #704 #1298 #1332 #1345 #1370 #1668 #1736 #1873 #1895 #2112 #2314 #2323 #2411
The reasons are complicated but basically typing.get_type_hints()
doesn't work all the time and neither do the numerous hacks we've introduced to try and get fix it. Even if typing.get_type_hints()
was faultless, it would still be massively slower than the current semantics or PEP 649 (see below).
In short - pydantic doesn't work very well with postponed annotations, perhaps it never will.
The Problem
The problem is that postponed annotations are set to be come default in 3.10, features of which will be frozen in about three week.
Even worse, there's no way to switch back to the current behaviour.
The Solution
The solution to this is PEP 649 developed by Larry Hastings. This basically means annotations evaluation is lazy - the work of building __annotations__
isn't done until you access __annotations__
.
As far as I can tell this is the best of both worlds.
The Second Problem
The sad reality however is that it seems very possible that PEP 649 will get rejected and when python 3.10 is released it will break much of pydantic, and thereby FastAPI and all the other libraries that rely on pydantic (as well as other libraries that use annotations at runtime like enforce and typer presumably).
See this very long discussion of the issue on python-dev about whether PEP 649 is a good idea.
The Point
So why am I saying all this apart from whinging about something I don't agree with?
1. This is fair warning
That pydantic might break in a big way if python's core developers continue value principle over pragmatism.
2. You can help
Thousands of developers and organisations big and small rely on pydantic. Type hints might have been conceived to help readers and static type checkers, but they're now used to great effect at runtime by lots and lots of people - they make python better.
In the end I don't think python's core developers and steering council want to make your experience of python worse. They just haven't realised how important this is. (Even Larry hadn't heard of pydantic or FastAPI until yesterday when he emailed me, I guess they don't read the python developer survey 😉)
~If you value pydantic or FastAPI or other libraries that use annotations at runtime, please (constructively and respectfully) let the python steering council know that you would like PEP 649 to be accepted.~ Please don't contact members of the python community, they're aware of this issue (see below) and are taking it seriously.
I understand the decision on PEP 649 will be made over the next few days, ~so if you're going to do anything do it today~.
Meta