What does "static and dynamic specifications" mean? Surely, there are
There are specifications for both the runtime and the static aspects of the Python programming language.
Python does not have a static checking phase,
The (C)Python *interpreter* doesn't. Other Python implementations (existing or hypothetical) may or may not have a static checking phase.
But static tools need specifications beyond (ie. additionally to) runtime specifications, which are defined in PEP 483, 484, 585 and others.
> Let us start from some anecdotal evidence: isinstance() is one of the most called functions in large scale Python code-bases (by static call count). In particular, when analyzing some multi-million line production code base, it was discovered that isinstance() is the second most called builtin function (after len()). Even taking into account builtin classes, it is still in the top ten. Most of such calls are followed by specific attribute access.
Why use anecdotal evidence? I don't doubt the numbers, but it would be
better to use the standard library, or the top N most popular packages
Maybe a scientific paper could be written on this subject. I'm guessing the "multi-million line production code base" in question is the Dropbox code base, and maybe Dropbox has an idiomatic way of writing Python with lots of "isinstance()"s.
> In general, we believe that pattern matching has been proved to be a useful and expressive tool in various modern languages. In particular, many aspects of this PEP were inspired by how pattern matching works in Rust  and Scala .
Both those languages are statically typed, which allows the compiler to
perform the much of the pattern matching at compile time.
You should give examples from dynamic typed languages instead, e.g. clojure.
Here's one example: