Mypy 0.980 Release Planning

[jhance]

I am planning to make a 0.980 release around late August.

Please post here any issues you'd like to see fixed in the release, or PRs you'd like to have merged. There is no release branch yet - I will update the issue once it exists.

[hauntsaninja]

Would be good to have a fix for #13227 (comment)
(note: I see Jukka happened to fix the message in #13382 )

[hauntsaninja]

As mentioned in that issue, it would also be good for mypyc docs to be built, they're getting really stale: mypyc/mypyc#920

[ilevkivskyi]

I would prefer my generic PRs included: #13389, #13396 (I mean I could just merge them, but ideally it would be great if someone looked at them)

[ilevkivskyi]

Thanks @JelleZijlstra for stepping up and reviewing the PRs!

[hauntsaninja]

Regression on master with subtyping of Type: #13303 (comment)

[ilevkivskyi]

Hm, it is not really about Type[...] by itself, it rather uncovered some existing inconsistencies. There actually two things: inconsistent type inference, and inconsistent overlapping for <nothing>.

On the first one, there are three ways a type inference can fail:

• Impossible to satisfy pair, like List[T] <: int
• Always satisfied pair, like List[T] <: object
• Pair that can't be satisfied because of type variable upper bound, like Lits[T] <: List[int], where T <: str.

The problem is that which way it goes may depend on whether T appears in a nested position and/or inside a union. For general call checking it is not very important, we just get different error messages. But the problem is that we use constraints inference for various other things, e.g. overload consistency checks. To illustrate, here is a minimal repro:

T = TypeVar("T", bound=str)
@overload
def foo(x: Type[T] | int) -> int: ...  # Bogus error: Overloaded function signatures 1 and 2 overlap with incompatible return types
@overload
def foo(x: Callable[[int], bool]) -> str: ...

What is weird here, is that if I remove the | int part, it passes, while it is obvious that int can't be the reason for overlap. And indeed the reason is that without the union we get Cannot infer type variable code path, and with the union we get T = <nothing> code path.

Another inconsistency is that is_overlapping_types() returns True if is_proper_subtype() returns True for some pair. This is peoblematic w.r.t. <nothing>. Namely, [] == [42] is a totally safe thing, so we should say list[<nothing>] and list[int] are overlapping. But for overload checks, we could say the are not overlapping, because we already ignore empty lists for e.g. list[int] vs list[str]. Another repro to illustrate:

T = TypeVar("T", bound=str)

@overload
def foo(x: List[T]) -> str: ...  # Same bogus error here.
@overload
def foo(x: Sequence[int]) -> int: ...

While it passes if I put a plain List[str] there.

Fixing either of issues will fix the bug. I am not sure what is the best way. On one hand, union inference is known to cause many problems (e.g. @jhance discovered another false positive in a similar situation just couple days ago), but on other hand it is a very dangerous thing to touch. So I will probably go with fixing the second, unless there are other ideas.

[ilevkivskyi]

OK, since I didn't hear any other ideas here is #13461 for the above issue.

[ilevkivskyi]

Btw #13471 would be great to include (it is low risk because it is behind --enable-incomplete-features anyway, and fixes currently most upvoted issue).

[ilevkivskyi]

Also I think #13381 would be good to include (fixes an annoying crash).

[cdce8p]

New crash on master #13536. Bisects to #13494

[ilevkivskyi]

Fix #13538 (but also I think will be after this release branch base)