PEP 563, PEP 649 and the future of pydantic · Issue #2678 · samuelcolvin/pydantic · GitHub

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.

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.