1.20 and 2.0 Release Planning · Issue #20726 · python/mypy · GitHub

OK, I think it is time to start discussing v1.20 and v2.0 releases more concretely. After some discussions it looks like we want to avoid the Python 2 vs 3 situation. So, it is better to limit the number of breaking changes to either:

Something that we really need (something that blocks other important things).
Something that is straightforward and causes minor fallout.

To further limit the impact, it is better to move few things to v1.20. This will give us an opportunity to attract some attention to upcoming breaking changes, and will give people some intermediate stepping stone for an upgrade. Below is a summary of proposed plan for the releases.

Proposed target timeline:

v1.20 out by end of February.
v2.0 out by end of March.
We should limit amount of unrelated commits between v1.20 and v2.0 to reduce additional damage from unrelated regressions in v2.0.

Things to be included in v1.20:

New parser as an experimental feature.
Make fixed format cache the default.
Detailed list of coming breaking changes in v2.0 with recommended mitigation strategies (in CHANGELOG.md and in blog post), possibly also spread the word about it on SM.
Encourage people (again) to try --allow-redefinition-new, and announce that it will be default semantics eventually, but not in v2.0.
Add --allow-redefinition-old as an alias to --allow-redefinition.

Things to be included in v2.0:

Parallel type checking (with the new parser only) as a beta feature.
Flip default for --local-partial-types.
Flip default for --strict-bytes.
Delete the Python 2 extra from setup.py.
Prevent assignment to None for class variables.
Remove logic for legacy bundled stubs, see Remove logic for legacy bundled stubs #18372.
Rename --allow-redefinition-new to --allow-redefinition (and keep --allow-redefinition-old). --allow-redefinition-new will continue to work as an alias to --allow-redefinition.

Things we need for v1.20 (blockers):

The new parser is feature complete (not necessarily fully parallelized yet).
Tool to convert fixed format cache to JSON is fully functional, PR is ready Update JSON export tool to support binary meta cache files #20096
Migration tool for --local-partial-types, see Create tool to help migration to --local-partial-types #20579.
Make sure the narrowing fixes stack is not in a "half way there" state.
Fix enough --allow-redefinition-new bugs to enable it in self-check.

Things we need for v2.0 (blockers):

New parser is fully parallelized.
Parallel checking works on Windows.
Fix any known incremental bugs that can affect parallel checking (I recently cleaned-up incremental issues).
Fix all known --allow-redefinition-new bugs, in particular --allow-redefinition-new does not mean "new" implementation but "new" variables #19918 should be a release blocker IMO.

Comments, suggestions, etc are welcome! We can also use this issue to coordinate on how do we split the necessary work.

cc @JukkaL @hauntsaninja

Yay!

My notes:

I would prefer we move removing logic for bundled stubs to v2. It doesn't eat disruption budget (it results in fewer errors for users) and if there are users who care they will be less surprised by this changing in a major release.
Do we still want to make SQLite cache the default?
There's like one and a half narrowing changes left for me to land to not be in an in-between state, anything else is more "missing features"
One narrowing thing I want advice on is if people have opinions on how to land the change that makes mypy (accurately) infer much more code as unreachable. I will post a follow-up comment with some details about this (I've been splitting up the relevant PR so that the primer diff is as tightly scoped as possible)
Could be worth remembering to add the --allow-redefinition-old alias in v1.20
There may also be changes we can land in v1.20 to make --local-partial-types smoother, e.g. one from yesterday Improve interaction between --local-partial-types and hashability #20719

There are some more features I would like to potentially land for v2 but these will either be uncontroversial or opt-in, we can discuss more if I start implementing them.

I would prefer we move removing logic for bundled stubs to v2. It doesn't eat disruption budget (it results in fewer errors for users) and if there are users who care they will be less surprised by this changing in a major release.

I have no strong opinion on this one. So I am fine either way, I will move this to v2.0.

Do we still want to make SQLite cache the default?

I am not 100% sure TBH. Anecdotally, there are some performance benefits, but they usually only appear in very large code bases. We can do this at some point, but I would say not in 1.20 or 2.0, where quickly debugging cache may be important. Also if we will decide to do this, this doesn't need to be tied to a major bump, I think it can be done in a minor version as well (cache format is an internal thing).

There's like one and a half narrowing changes left for me to land to not be in an in-between state, anything else is more "missing features"

OK, great!

One narrowing thing I want advice on is if people have opinions on how to land the change that makes mypy (accurately) infer much more code as unreachable. I will post a follow-up comment with some details about this (I've been splitting up the relevant PR so that the primer diff is as tightly scoped as possible)

I think this really depends on the details. Btw note there is also #18078 which I decided to not include in 2.0. Having --warn-unreachable in --strict may prevent false negatives, because we don't report errors in unreachable code. Btw, potentially we can also do this in a minor version a bit later, since many people consider this a bug.

Could be worth remembering to add the --allow-redefinition-old alias in v1.20

Good point! I will update the list.

There may also be changes we can land in v1.20 to make --local-partial-types smoother, e.g. one from yesterday #20719

Sure, if anyone has more ideas, please go ahead. FWIW I don't have any ideas right now.

Do we still want to make SQLite cache the default?

I think this is important, since it can result in visible performance gains for huge codebases, but possibly primarily on macOS/Windows where writing or reading many files tends to be slower than on Linux. The slow operations may be related to security products/features that hook into file system operations (which are not as common on Linux), but in any case I've experienced slow file system operations myself. I agree with Ivan that this doesn't need to be tied to any particular release, since it should have minimal user-visible impact beyond performance.

@hauntsaninja

should we try to get #15993 into one of these releases? With latest numpy we no longer have a primer diff

Good catch! I forgot about this one. Yes, I think we can even include this is v1.20 since technically old behavior is inconsistent and is a bug. However, we should probably also:

Recommend updating NumPy to 2.3.4+ in release notes
Add detailed documentation on how callable types work somewhere around here https://mypy.readthedocs.io/en/stable/class_basics.html#class-attribute-annotations (unless they are already somewhere in the docs). I mean these rules for Callables (and callback protocols):
- Explicit annotation without ClassVar -> instance variable (i.e. already bound type)
- Explicit annotation with ClassVar -> class variable (i.e. will be bound on instance access)
- Inferred type (e.g. a method alias) -> class variable
- Operator names like __add__ and __mul__ -> always class variable independently of rules above
- And a note that we only treat protocols with __call__ identically to Callable and these rules are not applied to regular callable objects because this is how Python works.

Internally rename allow_redefiniton to allow_redefinition_old (#20764)

If it's okay, I'd like to keep #15993 for 2.0 (not 1.20). It is a somewhat impactful change, also my workplace is still on an older numpy. I will add the documentation.

In terms of narrowing, my plan is to land at least the following for 1.20 since they fix regressions from the current narrowing rewrite:

Better handling of generics when narrowing #20863
Narrow Callable generic return types #20868 (and Remove prohibit_none_typevar_overlap #20864)
Improve reachability in narrowing logic #20660 (doesn't fix regression but will help users)

There are of course other narrowing changes I want to make, but it is okay for those to go into a future release too.

v1.20 out by end of February.

@ilevkivskyi, I'm wondering if this timeframe for 1.20 is still viable or do you expect delays? We are currently in the process of releasing Bokeh 3.9, which is blocked on issue #20671 (fixed in 1.20-dev and verified by us). We are weighing our options as to how to proceed with Bokeh's release.

Do you know if this suggestion worked? #20671 (comment) Mypy releases historically are usually a little behind schedule, but even if it is on track, I'd expect several users to hit the issue... so if there's a workaround we could put in place that feels like a good idea

Do you know if this suggestion worked?

We tried the suggested approach and it worked to an extent, but didn't fully resolve crashes.

@mattpap

I'm wondering if this timeframe for 1.20 is still viable or do you expect delays?

Unfortunately no, that was a bit too ambitious. Realistically it will be at least another week, proably two.

We tried the suggested approach and it worked to an extent, but didn't fully resolve crashes.

Hm, did you try adding a dummy private variable right after all the TypedDict definitions? E.g. like this:

class HasCyclicRefs(TypedDict):
    ...

_force_refs_resolution: HasCyclicRefs

Hm, did you try adding a dummy private variable right after all the TypedDict definitions? E.g. like this: (...)

I tried this suggestion as well, but nothing helps, just shifts crashes to a different subset of our codebase. For now we decided to revert our changes and continue with the release. We will restore them in the next minor release.

Hey, I have this PR which has been open since July:

[PEP 695] Fix incorrect Variance Computation with Polymorphic Methods. #19466

but it seemingly got stuck / forgotton about after some discussion. (last comment was in December). I recently discovered yet another case of incorrect variance inference that is also solved by this patch: #20997

Since it looks like there is some fundamental disagreement here (#19466 (comment), #19466 (comment)), I was wondering whether one or two additional members of the mypy project could take a look at this as well and advice on whether or not this can be patched or should be clarified in python/typing first.

An update from offline discussion with @JukkaL: he will be the release manager for v1.20. IIUC release branch will be cut soon.

Btw just do double-check, @JukkaL did you test switching to --allow-redefinition-new in internal code bases with the recent master? Also it would be great to test parallel checking in internal code bases after #20991 is merged (hopefully soon).

I've tested --allow-redefinition-new at a small scale and encountered no issues. I'll do some more experimentation before the release.

I can test parallel checking after the PR gets merged.

I'm also working on a fix to #8055, which I'd like to get merged before cutting the release branch, since it can speed up initial mypy runs by up to 10x on macOS.

@ilevkivskyi Double checking if there are still some major features that should get a separate section in changelog would help (if you can do it in the next hour or two). I hope we get the release out by the end of the day today. I'm going to prepare the final release notes soon.

@JukkaL I just double-checked, all major changes are included in changelog.

Changelog for mypy 2.0 (#21422)

Could #21407 be cherry-picked as well? It would make using --num-workers a bit easier.

We'll likely have a 2.1 release (very) soon, so it will be included in that release.

Changelog for mypy 2.0 (#21422)

mypy 2.0 is out: https://mypy-lang.blogspot.com/2026/05/mypy-20-relased.html

@JukkaL Great! I guess it is time to add a news item to https://mypy-lang.org/ as well.

@Dreamsorcerer if your frozenlist thing repros with mypy 2, could you open a new issue

Reported regressions:

[2.0 regression] Crash with --allow-redefinition on partial type with global #21423 (crash)
[2.0 regression] TypeVar with constrains Sub and Super does not accept Sub as a default value #21424
[2.0 regression] INTERNAL ERROR: AssertionError in visit_decorator_inner on @types.coroutine generator function #21426 (crash)
[2.0 regression] check_call in a plugin started producing a wrong output #21427

(feel free to edit)

I updated https://mypy-lang.org/ .

I started working on the 2.1 release (#21450), to be released in two or three days. It's unclear if it's worth having a 2.0.1 in addition to 2.1 -- I don't have a strong opinion.

@JukkaL I don't think we need 2.0.1. Instead, we should cherry-pick any remaining regression fixes to 1.20 and make 1.20.3 release say around end of next week.

@JukkaL @hauntsaninja Do you think it would make sense to release 1.20.3 ~soon that would include cherry-picks for some late-reported regressions like #21535? (There are probably few more)

I don't have a strong opinion yet about 1.20.3 -- I'll look at the available cherry picks first to get a better feel for what might be included.

1.20 and 2.0 Release Planning · Issue #20726 · python/mypy · GitHub

Repository navigation

1.20 and 2.0 Release Planning #20726

90 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

1.20 and 2.0 Release Planning · Issue #20726 · python/mypy · GitHub

Repository navigation

1.20 and 2.0 Release Planning #20726

Description

Activity

hauntsaninja commented on Feb 3, 2026

ilevkivskyi commented on Feb 3, 2026

JukkaL commented on Feb 4, 2026

ilevkivskyi commented on Feb 10, 2026

hauntsaninja commented on Feb 23, 2026

mattpap commented on Feb 26, 2026

hauntsaninja commented on Feb 26, 2026

mattpap commented on Feb 26, 2026

ilevkivskyi commented on Feb 26, 2026

mattpap commented on Mar 9, 2026

randolf-scholz commented on Mar 9, 2026

ilevkivskyi commented on Mar 11, 2026

JukkaL commented on Mar 12, 2026

90 remaining items

JukkaL commented on May 6, 2026

ilevkivskyi commented on May 6, 2026

JukkaL commented on May 6, 2026

JukkaL commented on May 6, 2026

ilevkivskyi commented on May 6, 2026

hauntsaninja commented on May 7, 2026

hauntsaninja commented on May 7, 2026

JukkaL commented on May 7, 2026

JukkaL commented on May 9, 2026

ilevkivskyi commented on May 10, 2026

ilevkivskyi commented on May 21, 2026

JukkaL commented on May 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions