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)

[hauntsaninja]

Oh have we cut the release branch base? I don't see it in https://github.com/python/mypy/branches...
If you post the commit here I can mention if I think there are things on master that are important that didn't make it in

[ilevkivskyi]

I talked to @jhance privately few days ago, and he told me he is thinking about making 4d4326a the base of release branch.

[ilevkivskyi]

Hm, actually I am not sure now, he said "last typeshed sync", but I am not sure which one he meant.

[hauntsaninja]

We should make sure to include #13500 in the next release. Currently users of Python 3.10.7 and numpy are broken.

If you create the release branch, I can make sure to backport any necessary changes.

[AlexWaygood]

We should make sure to include #13500 in the next release. Currently users of Python 3.10.7 and numpy are broken.

+1, we've had two duplicates reported today

[zevisert]

We should make sure to include #13500 in the next release. Currently users of Python 3.10.7 and numpy are broken.

Yes please! I spent almost two hours before finding the closed issues for this today (my project's mypy version didn't change (still 0.942, just the python version bump). The longer we wait for #13500, the more people will have adopted 3.10.7 and come reporting this here again

Edit: Thank you for pinning, I think that's actually a great way to spread awareness

[tdsmith]

#13425 is causing a lot of noise for my group and it ended up landing juuuuuust the wrong side of the line; we'd be grateful to see it in this release.

[hauntsaninja]

Backport PR for tdsmith's change here: #13644

[AlexWaygood]

Typeshed's test suite is currently quite badly broken on the master and release-0.980 branches:

• stubtest --custom-typeshed-dir broken on master and 0.980 #13654

[hauntsaninja]

Backport PR for the custom typeshed dir regression here: #13658

[ilevkivskyi]

@hauntsaninja Thanks for fixing this!

[cdce8p]

Backport PR to fix tests with 3.10.7: #13665

[intgr]

Maybe also backport #13687, tweaks the error message of a new check added in 0.980.

[J08nY]

Is there any updated ETA on this? Original comment mentions late August while it is mid-September now and at least the #13500 issue is biting more and more users as they update to Python 3.10.7.

[jhance]

Released: https://mypy-lang.blogspot.com/2022/09/mypy-0981-released.html

[hauntsaninja]

Typo in the blogpost: I think add_button("OK", tight) # This works as well should be add_button("OK", **tight)

[jhance]

Ugh, I fixed that for the kwargs elsewhere. It seems like the script we use to convert to html has some bug

I fixed the tight

[hauntsaninja]

If we make a 0.982, we should take #13461

Caused issue reported here: #13750 and regression on typeshed: python/typeshed#8796 (comment) / #13303 (comment)

[JohnVillalovos]

Just curious what will be the release version after 0.990? 1.0?

[AlexWaygood]

Just curious what will be the release version after 0.990? 1.0?

Yes; see #13685 for details

[hauntsaninja]

Two regressions in 0.980 at #13756 and #13760. Both repro on master / I link the PRs that introduced the regressions

Also we could cherry pick #13730 to help with some questions like #13765

[ilevkivskyi]

I think we can also CP #13784

[ilevkivskyi]

An also #13778. I will probably CP the three mentioned PRs (in addition to the one I already CPed) and will bump the minor version so everything will be ready for the bugfix release on Monday.

[ilevkivskyi]

Oh wait, modules as protocol implementations were not included in the release, so we don't need the last one.

[ilevkivskyi]

Done, everything is ready for the point release. cc @jhance