* Add PYTHON314_PREFIXES to CompatibilityVisitor
* Patch typeshed, add t-string related stubs
* Infer `string.templatelib.Template` type for t-strings instead of plain `str`
GitOrigin-RevId: 0e913910ab9e0dca4052856b0585ce66265291c0
New Tensorflow Typeshed has updated stubs for the keras module, as well as for other Tensorflow modules. So PY-65966 should not be reproducible anymore
GitOrigin-RevId: 929e1da40c82bf6dd26efd227c0421087df3b75c
The root cause was introduced in PY-23540 (see cb598c94c5).
Namely, abs.ABCMeta was explicitly filtered out from the list of metaclasses in
`PyClassImpl.getMostDerivedClassType` because for some reason in Typeshed stubs for
Python 2 `basestring`, and hence `str`, uses `ABCMeta` as its metaclass,
which is not true at runtime. It caused a metaclass conflict when inheriting `str`
with another user-defined metaclass (`ABCMeta` and a user metaclass didn't extend
each other), so we didn't detect any metaclass in a class as a result.
I've updated Typeshed stubs for Python 2 manually to process ABCMeta normally.
We don't update these stubs anyway, so these changes won't be lost on a future
Typeshed sync.
GitOrigin-RevId: 680e9fa890d00ea63987f3cf73e636e430685f34
I've add-hoc updated typing_extensions.pyi in the bundled Typeshed to
recognize Unpack there.
GitOrigin-RevId: 953402e42984712a630c1772cf2f2cd4cbacdccf
The introduction of TypeVarTuples and the concept of unpacked tuple types made us
revise all the places where we match sequences of types in type inference.
For instance, when matching type parameters and type arguments for generic
specialization in:
* type hints, i.e. xs: MyGeneric[int, str] = MyGeneric()
* constructor invocations, i.e. xs = MyGeneric[int, str]()
* class declarations, i.e. class MyGeneric(Base[T1, T2, str]): ...
* type alias declarations, i.e. MyAlias: TypeAlias = MyGeneric[T, int]
as well as during type matching of all generic types, both normal non-variadic and
existing "built-in" generic variadics in the type system, namely tuples and
Callables.
Previously, this logic was spread across numerous places in PyTypeChecker and
PyTypingTypeProvider, all with their own subtle differences. The first attempt
of PEP 646 support put all the code for uniform matching of type parameters directly
in PyTypeChecker, significantly complicating its already arcane internals.
I've introduced a unified API for that called PyTypeParameterMapping.
It still retains some of the former quirks in form of its Option flags, controlling
in particular how we handle having some of the expected types unmatched
(imagine expecting MyGeneric[T1, T2, *Ts] and receiving MyGeneric[int]),
but I'm planning to gradually eliminate this conditional logic.
The same class is now also responsible for matching parameter types of callables
that already allowed to fix some of the known problems, such as ignoring their
arity (PY-16994), but I'm going to extract a separate API entity for that, since
matching of callable signatures is a much more complicated task involving
compatibility of different types of parameters (positional-only, keyword-only,
defaults, varargs, etc.).
Another positive side effect of these changes is that substitution of type
parameters during type inference became more consistent, and we no longer lose
useful type information by replacing all unbound type parameters with Any. It's
particularly visible in type checker errors where we stopped dropping unbound type
parameters from messages about mismatched parameter-argument types.
Among other improvements in this changeset are proper scoping for
TypeVarTuples, consistent with other type parameters, and recognizing TypeVarTuples
and unpacked tuples in types of *args parameters in function bodies, e.g.
`*args: *Ts` translates to "args" parameter having the type `tuple[*Ts]`.
Confusing PyNoMatchedType used only for reporting of missing arguments for *args
parameters annotated with unpacked tuples in the type checker inspection, e.g.
def f(*args: *tuple[int, str]): ...
f(42) # a type checker error about a missing argument for str
was also removed from the type system in favor of a simpler approach with handling
such errors directly in the inspection. We might need such a general type in
the future, but it has to be well thought-through.
GitOrigin-RevId: 63db6202254205863657f014632d141d340fe147
Since PY-53896 got implemented, I'm making builtins up-to-date. They were reverted to workaround PY-52648 & PY-52656
GitOrigin-RevId: f7bacdc06c0bc0669ec8cb65ec64eec02834d2a1
Its absence made Py3TypeCheckerInspectionTest.testPathlibPathMatchingOsPathLike
fail as os.PathLike protocol wasn't considered generic. Once the changes
for generics are in the upstream, we will be able to update the Typeshed
fully at long last.
GitOrigin-RevId: 1333cc19bff15e328996c57362124a7fdb5ab057
Type annotation Model for SQLAlchemy.Model will appear in 6a9c06edb95c9ecae7a76789e906fbbd420e5a25
GitOrigin-RevId: a4c601d534630253489fef55d08ce5afaa41d3c4
The changes in typeshed will be in 0e4ea44080cff090ead62943de15487963ef0b2a and 234250384dad99367c181f2c8e2370ae2a2e3e83 revisions
GitOrigin-RevId: 9ee9953b0efa7f98cac2ee23756a30cf25e0fdb2
This is a workaround until PY-53896 is implemented.
It effectively brings the stubs for builtins in Typeshed to their state at
37ee52ec2d883d8bbf244e4d1a871cde7f678d17, with the exception that I kept new
definitions for __build_class__ and ExceptionGroup (for 3.11).
GitOrigin-RevId: 92fdf169d228c52bcefa7edc3f185cb931ff4d79
