Users of a library will generally instruct their type-checker not to check the library.

So only the outer API surface of the library matters. That’s mostly explicitly typed functions and classes so the room for different interpretations is lower (but not gone).

This is obviously out the window for libraries like Pydantic, Django etc with type semantics that aren’t really covered by the spec.

You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.

At least some of it is differing policies on what types can be inferred/traced through the callers vs what has to be given explicitly.

I think everyone basically agrees that at the package boundary, you want explicit types, but inside application code things are much more murky.

(plus of course, performance, particularly around incremental processing, which Astral is specifically calling out as a design goal here)

> Do library authors have to test against every type checker to ensure maximum compatibility?

Yes, but in practice, the ecosystem mostly tests against mypy. pyright has been making some inroads, mostly because it backs the diagnostics of the default VS Code Python extension.

> Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?

You can provide your own type stubs instead of using the library's built-in types or existing stubs.

I am not that surprised, to be honest. Basically every C/C++ static analyzer out there does (among other things) some amount of additional "custom" type checking to catch operations that are legal up to the standard, but may cause issues at runtime. Of course in Python you have gradual typing which adds to the complexity, but truly well-formalised type systems are not that common in the industry.