Repository navigation
Release 0.940 planning #12021
Description
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.
Activity
AlexWaygood commented on Jan 19, 2022
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):
cdce8p commented on Jan 19, 2022
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.
hauntsaninja commented on Jan 19, 2022
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 commented on Jan 19, 2022
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.
RJPercival commented on Feb 1, 2022
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 commented on Feb 2, 2022
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 commented on Feb 6, 2022
List of my PRs that I would like to see in this release.
Easy
Enum
Dataclasses
python2
TypeGuard
More complex ones
Most of the PRs below will change inference:
Cache related:
Most of them aren't reviewed yet 🙂
hauntsaninja commented on Feb 17, 2022
@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 commented on Feb 18, 2022
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:
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 commented on Feb 18, 2022
Here's the rough priority order of my next tasks:
AlexWaygood commented on Feb 27, 2022
srittau commented on Mar 1, 2022
@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 commented on Mar 1, 2022
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 commented on Mar 9, 2022
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.
9 remaining items
JukkaL commented on Mar 21, 2022
Additional potential regressions:
JukkaL commented on Mar 24, 2022
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 commented on Mar 24, 2022
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:
In the past the type would resolve to S*[Any]. Is the new behaviour intended?
JelleZijlstra commented on Mar 24, 2022
@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 commented on Mar 24, 2022
@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
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
Setting explicit type to decision variable makes it work.
hauntsaninja commented on Mar 24, 2022
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 commented on Mar 24, 2022
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:
and for 0.942 (0.94x actually):
hauntsaninja commented on Mar 25, 2022
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:
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 commented on Mar 25, 2022
@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 commented on Mar 25, 2022
@hauntsaninja Thanks for the explanation.
@intgr I understand where are you coming from, but such comments are not helpful.
JelleZijlstra commented on Mar 25, 2022
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 commented on Mar 25, 2022
@JelleZijlstra I just followed advice in this comment #12021 (comment). Please decide on the process and I am more than happy follow it. 🤷
AlexWaygood commented on Apr 10, 2022
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 commented on Apr 11, 2022
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).