You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Polymorphic inference: support for parameter specifications and lambdas (#15837)
This is a third follow-up for #15287
(likely there will be just one more PR, for `TypeVarTuple`s, and few
less important items I mentioned in the original PR I will leave for
more distant future).
After all this PR turned out to be larger than I wanted. The problem is
that `Concatenate` support for `ParamSpec` was quite broken, and this
caused many of my tests fail. So I decided to include some major cleanup
in this PR (I tried splitting it into a separate PR but it turned out to
be tricky). After all, if one ignores added tests, it is almost net zero
line count.
The main problems that I encountered are:
* First, valid substitutions for a `ParamSpecType` were: another
`ParamSpecType`, `Parameters`, and `CallableType` (and also `AnyType`
and `UninhabitedType` but those seem to be handled trivially). Having
`CallableType` in this list caused various missed cases, bogus
`get_proper_type()`s, and was generally counter-intuitive.
* Second (and probably bigger) issue is that it is possible to represent
`Concatenate` in two different forms: as a prefix for `ParamSpecType`
(used mostly for instances), and as separate argument types (used mostly
for callables). The problem is that some parts of the code were
implicitly relying on it being in one or the other form, while some
other code uncontrollably switched between the two.
I propose to fix this by introducing some simplifications and rules
(some of which I enforce by asserts):
* Only valid non-trivial substitutions (and consequently upper/lower
bound in constraints) for `ParamSpecType` are `ParamSpecType` and
`Parameters`.
* When `ParamSpecType` appears in a callable it must have an empty
`prefix`.
* `Parameters` cannot contain other `Parameters` (and ideally also
`ParamSpecType`s) among argument types.
* For inference we bring `Concatenate` to common representation (because
both callables and instances may appear in the same expression). Using
the `ParamSpecType` representation with `prefix` looks significantly
simpler (especially in solver).
Apart from this actual implementation of polymorphic inference is
simple/straightforward, I just handle the additional `ParamSpecType`
cases (in addition to `TypeVarType`) for inference, for solver, and for
application. I also enabled polymorphic inference for lambda
expressions, since they are handled by similar code paths.
Some minor comments:
* I fixed couple minor bugs uncovered by this PR (see e.g. test case for
accidental `TypeVar` id clash).
* I switch few tests to `--new-type-inference` because there error
messages are slightly different, and so it is easier for me to test
global flip to `True` locally.
* I may tweak some of the "ground rules" if `mypy_primer` output will be
particularly bad.
---------
Co-authored-by: Ivan Levkivskyi <[email protected]>
0 commit comments