Release 0.940 planning

[JukkaL]

I'm planning to make a 0.940 release in February (tentative timeline). If things go according to plan, I'd cut the release branch in the first half of February.

Here are some things that I'd like to have in the release:

• Reachability/exhaustiveness checking for match statements #12010
• Basic ParamSpec Concatenate and literal support #11847
• Make --namespace-packages the default #9636

We also need at least one typeshed sync.

Any help with the above issues would be greatly appreciated!

Please post here any issues you'd like to see fixed in the release, or PRs you'd like to have merged. After cutting the release branch, only high-priority fixes can be cherry-picked.

[AlexWaygood]

For typeshed, having the following issues fixed would be really nice, if at all possible (I'm trying to work on a solution for the first two in #11915 -- but note that it'll only work for stub files; the bugs will still be there for .py files):

• Implicit type aliases not recognised with PEP 604 + import cycles #11887
  • still an issue for .py files, but now fixed for stub files by Fix "Implicit type aliases not recognised with PEP 604 + import cycles" (but only for stubs) #11915 🥳
• (🐞) False positive "error: Type application has too many types (1 expected)" on tuple when annotated as a type or in a TypeAlias with new union syntax (PEP 604) #11098
• Crash when (Mutable)Sequence is imported from collections.abc in typeshed/stdlib/builtins.pyi #11860

[cdce8p]

I would like to suggest my PR from summer last year. It's something that already works in pyright. Once mypy supports it the remaining type checkers might consider it too if they haven't already. It could help cut down duplicate overload definitions in typeshed. The PR is fully tested and only waiting for review.

• Add support for conditionally defined overloads #10712

[hauntsaninja]

I have an almost green typeshed sync here: #11905
It's currently blocked on a single regression (which in my mind isn't a release blocker)

I'd like to get #12023 merged (the crash is blocking me at work / has been reported many times).

#12005 is an issue we should fix (somewhat, but not fully related to #11887 which we should also fix, but is trickier and not quite as bad).

[henryiii]

I'd really like to see Self support make it in, since it's in typing_extensions and supported by several other type checkers, and was just accepted by the SC. But understandable if it isn't finished in time.

• Implementation of PEP 673 (typing.Self) #11666

[RJPercival]

Is there any chance of getting a v0.932 in the meantime so that we can get fixes for #11850 and #12132 (enum bugs) released please? These bugs have made mypy unusable for my project.

[intgr]

I, for one, would prefer a release of functionality that is already merged, on a shorter timescale. I would very much like to see mypy adopt time-based releases, rather than going through a feature crunch that sometimes delays useful working contributions for months.

The wait for version 0.920 was literally painful for me and my team. Now I'm waiting for support for match statement that was merged 2 weeks ago. It's not perfect, but it's better than the current state of even not being able to suppress warnings on match statements (#11829).

[sobolevn]

List of my PRs that I would like to see in this release.

Easy

Enum

• Adds StrEnum support for python3.11 #12035
• Check Enum definition for invalid base classes #12026
• Adds docs about Enum type #11805

Dataclasses

• Adds __hash__ method to @dataclasses.dataclass, refs #11463 #11496
• Add match_args support to attr.s() #12111
• Add match_args support to attr.s() #12111

python2

• Handle raise Exception(), None on Python2.7 #11786
• Use __truediv__ for python2 with __future__ import, refs #11740 #11787

TypeGuard

• Disallow to use TypeGuard type outside of .ret_type, refs #11765 #11790
• Fixes generic inference in functions with TypeGuard, refs #11780 #11797

More complex ones

Most of the PRs below will change inference:

• Adds Literal type math #11992
• Fixes how ** affects inference in {} expressions, refs #11691 #11693
• Fixes type inference for generic calls in if expr #11128
• Now overloads with ambiguous self are handled properly #11366
• Recognize Hashable as a real protocol, refs #11799 #11802

Cache related:

• @classmethod and @staticmethod were not shown in error messages when cached #11793

Most of them aren't reviewed yet 🙂

[hauntsaninja]

@JukkaL thoughts on release timeline? master is starting to accumulate a number of nice fixes (including some that would be appreciated at my day job)

[JukkaL]

Sorry for the delay! We've had a few(!) viruses going through our family in the last weeks. I was only able to start work on the release yesterday. Since we are late, I'm thinking of focusing on 3.10 features and low-risk changes only. This would mean postponing at least this change to the next release:

• Make --namespace-packages the default #9636 (postponed)

I agree that the release process hasn't been going too smoothly in the last several releases. We can discuss options for speeding up releases separately. I've been working on some process changes that may make it feasible to switch to monthly releases, for example, but we'd probably need one or two extra volunteer release managers to help share the work. I opened #12210 to discuss the release process.

[JukkaL]

Here's the rough priority order of my next tasks:

1. Investigate and fix/work around some regressions I've found (including Temporary moratorium on literal constants (until the end of 2022) typeshed#7258)
2. Python 3.10 feature work (match statement, ParamSpec improvements) (time boxed)
3. Merge other fixes and improvements (time boxed)
4. Make the release!

[AlexWaygood]

• Regression on master branch: false-positive error for enum mixin data types #12258 is a regression on the master branch that doesn't occur on mypy 0.931. (EDIT: Now fixed -- thanks @sobolevn!)

[srittau]

@hauntsaninja Could you also make sure that all stubtest improvements that we depend on in typeshed get into this release? I would like to switch back to stable/matching stubtest and mypy versions ASAP.

[hauntsaninja]

Yes, will try to stay on top of it. Though the issue in my mind is actually more with "stubtest improvements on mypy master that typeshed does not yet use" than "stubtest improvements on mypy master that might not be in 0.940" (e.g. python/typeshed#7346 )

[JukkaL]

After a few additional hiccups, I've cut the release branch. ParamSpec support is postponed to the next release, since there were some open issues. Match statement support is included in this release, including exhaustiveness checking.

I'm planning to make the release this Friday, if no significant regressions are found until then. I can cherry-pick low-risk fixes to the release branch until then.

The next feature release (probably 0.950) will go out on an accelerated schedule.

[JukkaL]

The release is now out: http://mypy-lang.blogspot.com/2022/03/mypy-0940-released.html

If you encounter or suspect a regression, please leave a comment here.

[twoertwein]

If you encounter or suspect a regression, please leave a comment here.

Potential regression #12335 maybe related to the conditional overloads?

[wrobell]

Possible regression for Mypy 0.940:

import typing as tp
from contextlib import asynccontextmanager

T = tp.TypeVar('T')

@tp.overload
def f() -> tp.AsyncContextManager[int]:
    ...

@tp.overload
def f(cls: type[T]) -> tp.AsyncContextManager[T]:
    ...

@asynccontextmanager
async def f(cls=int):  # type: ignore
    yield 1

Errors:

$ mypy --strict tp.py
tp.py:14: error: Overloaded function implementation cannot produce return type of signature 1
tp.py:14: error: Overloaded function implementation cannot produce return type of signature 2

No issue with 0.931.

[hauntsaninja]

That bisects to a typeshed change: [e266cdf] Sync typeshed (#11905)

[cdce8p]

Potential regression #12335 maybe related to the conditional overloads?

• Fix small conditional overload regression #12336

[hauntsaninja]

Linking #12339 / #12340

[RJPercival]

This enum regression, introduced by mypy v0.930, is still present: #12132

[JukkaL]

Released a hotfix release 0.941 with #12340 since it seemed to affect many users.

We'll have at least one additional bugfix release, probably either later this week or the next week.

[JukkaL]

Additional potential regressions:

• Significant speed degradation from 0.931 to 0.941 #12408 (not enough detail to reproduce)
• Inheriting from two data classes causes error Definition of "__match_args__" in base class "A" is incompatible with definition in base class "B" #12349

[JukkaL]

Mypy 0.942 is out with fixes to several regressions: https://mypy-lang.blogspot.com/2022/03/mypy-0942-released.html

At least the performance regression is still open.

[wrobell]

Please consider possible regression

import dataclasses as dtc
import typing as tp

T = tp.TypeVar('T')

@dtc.dataclass(frozen=True)
class S(tp.Generic[T]):
    f: tp.Callable[[T], str]

def f1(a: int) -> str:
    return str(a + 1)

def f2(a: str) -> str:
    return a + "1"

decision = {
    True: S(f1),
    False: S(f2),
}

reveal_type(decision[True])
reveal_type(decision[False])

Mypy 0.942 ouputs:

issues-mypy/t8.py:21: note: Revealed type is "builtins.object*"
issues-mypy/t8.py:22: note: Revealed type is "builtins.object*"

In the past the type would resolve to S*[Any]. Is the new behaviour intended?

[JelleZijlstra]

@wrobell I tried that in the playground and got the same behavior in 0.930 and as far back as mypy 0.620. I doubt it's a recent change. Which version was showing a different behavior?

[wrobell]

@JelleZijlstra I can replicate with my original codebase. Cannot replicate with the example above anymore. Not sure what's going on...

But there is still something consistently fishy. Please consider for ver. 0.942

import dataclasses as dtc
import typing as tp

R: tp.TypeAlias = str | int
T = tp.TypeVar('T', R, float)

@dtc.dataclass(frozen=True)
class S(tp.Generic[T]):
    v: type[T]
    f: tp.Callable[[T], str]

def f1(a: int) -> str:
    return str(a + 1)

def f2(a: str) -> str:
    return a + "1"

decision = {
    True: S(int, f1),
    False: S(str, f2),
}

reveal_type(decision[True])
reveal_type(decision[False])

then

$ mypy -V
mypy 0.942
$ mypy --strict issues-mypy/t8.py
issues-mypy/t8.py:19: error: Argument 2 to "S" has incompatible type "Callable[[int], str]"; expected "Callable[[Union[str, int]], str]"
issues-mypy/t8.py:20: error: Argument 2 to "S" has incompatible type "Callable[[str], str]"; expected "Callable[[Union[str, int]], str]"
issues-mypy/t8.py:23: note: Revealed type is "t8.S*[Union[builtins.str, builtins.int]]"
issues-mypy/t8.py:24: note: Revealed type is "t8.S*[Union[builtins.str, builtins.int]]"
Found 2 errors in 1 file (checked 1 source file)

When there are errors present, then the type is resolved to S*[str | int]].

Let' try this:

import dataclasses as dtc
import typing as tp

R: tp.TypeAlias = str | int
T = tp.TypeVar('T')

@dtc.dataclass(frozen=True)
class S(tp.Generic[T]):
    v: type[T]
    f: tp.Callable[[T], str]

def f1(a: int) -> str:
    return str(a + 1)

def f2(a: str) -> str:
    return a + "1"

decision: dict[bool, S[str] | S[int]] = {
    True: S(int, f1),
    False: S(str, f2),
}

reveal_type(decision[True])
reveal_type(decision[False])

then

$ mypy --strict issues-mypy/t8.py
issues-mypy/t8.py:23: note: Revealed type is "Union[t8.S[builtins.str], t8.S[builtins.int]]"
issues-mypy/t8.py:24: note: Revealed type is "Union[t8.S[builtins.str], t8.S[builtins.int]]"

Setting explicit type to decision variable makes it work.

[hauntsaninja]

Since this isn't a regression, let's move discussion to a separate issue. The original example looks correct to me; note that if you use T = tp.TypeVar('T', covariant=True) you'd get Revealed type is "__main__.S*[builtins.object]".

[wrobell]

Please consider this example instead

import dataclasses as dtc
import typing as tp

R1: tp.TypeAlias = str | int
R2: tp.TypeAlias = list | dict
T = tp.TypeVar('T', R1, R2)

@dtc.dataclass(frozen=True)
class S(tp.Generic[T]):
    f: tp.Callable[[T], str]

def f1(a: str | int) -> str:
    return str(a) + '1'

def f2(a: list | dict) -> str:
    return str(a)

#decision: dict[bool, S[str] | S[int]] = {
decision = {
    True: S(f1),
    False: S(f2),
}

reveal_type(decision[True])
reveal_type(decision[False])

Then for 0.931:

(venv) $ mypy -V
mypy 0.931
(venv) $ mypy issues-mypy/t8.py
issues-mypy/t8.py:24: note: Revealed type is "t8.S*[Any]"
issues-mypy/t8.py:25: note: Revealed type is "t8.S*[Any]"

and for 0.942 (0.94x actually):

$ mypy -V
mypy 0.942
$ mypy issues-mypy/t8.py
issues-mypy/t8.py:24: note: Revealed type is "builtins.object*"
issues-mypy/t8.py:25: note: Revealed type is "builtins.object*"

[hauntsaninja]

Thanks, the change in behaviour here is from fixing a bad bug on my part that caused TypeAlias to work incorrectly and be treated as Any when using aliased imports: #12180

If you change your example to use:

from typing import TypeAlias

R1: TypeAlias = str | int
R2: TypeAlias = list | dict

you'll find that it reveals "builtins.object*" even on 0.931 (that is, modulo the TypeAlias recognition bug, the underlying type checking logic is the same).

Overall, you'll still likely find you want to use a covariant type var.

[intgr]

@wrobell If you want to report bugs, please open a separate issue and link to it -- rather than spamming the comment thread of another issue.

[wrobell]

@hauntsaninja Thanks for the explanation.

@intgr I understand where are you coming from, but such comments are not helpful.

[JelleZijlstra]

I actually agree with @intgr though I might not have used the same words. For any other regressions, please open a new separate issue and just leave a brief comment here linking back to the issue. That way, we can keep the conversation more focused.

[wrobell]

@JelleZijlstra I just followed advice in this comment #12021 (comment). Please decide on the process and I am more than happy follow it. 🤷

[AlexWaygood]

I'm not sure if it's related to the recent release or not (it might have also happened on 0.931), but a lot of people seem to be running into #12475, which appears to be a relatively recent regression

[hauntsaninja]

Closing the issue, since it's been >1 month since 0.940 and I don't see us putting out another bugfix release. Unfortunately there doesn't yet seem to be a repro for #12475 (if it even is a regression, e.g. the original report mentions that they think it happened with 0.931 as well).