1.12/1.13 Release Tracking Issue

[hauntsaninja]

It would be nice to make a release. It's been about two months since 1.11. We have a couple nice changes in there and it'd be great to release a version of mypyc that should work on Python 3.13.0 (which should be released in about a week).

Do any of the Dropbox folk have time to drive a release?

[cdce8p]

Just to clarify, would you like a new release now (before 3.13.0) or afterwards with compiled binaries for 3.13? For the later, we'd probably need to wait for cibuildwheel to be updated.

Of course it'd also be possible to do a 1.12.1 release with the binaries once the new Python release is out.

[JukkaL]

I was already planning to start the release process this week :-)

I was waiting for Python 3.12 type parameter syntax to be officially supported and enabled by default. Mypyc support for 3.13 and compiled binaries for 3.13 would a great addition!

I'm planning to cut the release branch by the end of the week.

Just to clarify, would you like a new release now (before 3.13.0) or afterwards with compiled binaries for 3.13?

It looks like the planned release date for 3.13.0 is Oct 1. 1.12 won't be released before Oct 1, so it's possible that we could include compiled binaries for 3.13. If cibuildwheel doesn't get updated soon enough, we can make a 1.12.1 release afterwards.

[mr-c]

For the later, we'd probably need to wait for cibuildwheel to be updated.

I was curious about this and found mypyc/mypy_mypyc-wheels#82 which is failing against 5c38427 from September 16th.

Testing Python 3.13 mypy wheels won't work until Python 3.13.0 final (with the recently merged python/cpython#124273) is released, and cibuildwheel is updated to use it.

However, that requires no code changes, one can upload additional wheels to PyPI at any time.

As a downstream packager of mypy for Debian and the recipient of many Dependabot notifications, I would request that there isn't a "1.12.1" mypy release without code changes.

So hopefully mypy 1.12.0 can be released with Python3.13 wheels, or those wheels can be built & uploaded later without needing a "no-change" 1.12.1 mypy release.

[JukkaL]

However, that requires no code changes, one can upload additional wheels to PyPI at any time.

I guess we can upload new wheels, but only if they become available within a few days of the mypy release -- otherwise it could be confusing.

As a downstream packager of mypy for Debian and the recipient of many Dependabot notifications, I would request that there isn't a "1.12.1" mypy release without code changes.

Is the issue the busywork caused by such a release, or is there something else?

[mr-c]

However, that requires no code changes, one can upload additional wheels to PyPI at any time.

I guess we can upload new wheels, but only if they become available within a few days of the mypy release -- otherwise it could be confusing.

Hmm.. I don't see why it would be confusing? I understand that your automated script might not be setup to do that as of today.

As a downstream packager of mypy for Debian and the recipient of many Dependabot notifications, I would request that there isn't a "1.12.1" mypy release without code changes.

Is the issue the busywork caused by such a release, or is there something else?

The busywork would be annoying, yes :-)

[JukkaL]

Hmm.. I don't see why it would be confusing?

There is a small risk that the initial compiled binary for 3.13 would contain bugs specific to the compiled version, so anybody that has been using mypy pinned to 1.12.0 on Python 3.13 would suddenly start experiencing new issues.

[hauntsaninja]

As of #17812 we know for sure that the test suite passes with a mypyc-compiled mypy on latest Python 3.13

I feel good about the odds that our 3.13 build stack is ready for us by the time we release 1.12. And thank you to cdce8p for keeping cibuildwheel up-to-date / handling the cibuildwheel regression

[cdce8p]

Just did one more typeshed sync before the release branch is cut:

• Sync typeshed #17833

[JukkaL]

I've been testing the latest master, and I've found one release blocker so far:

• Wrong type inferred when "not in" narrowing Any  #17841

[JukkaL]

This release will fix many false negatives in an internal codebase I'm using for testing. This is great, but it slows down the testing process, since I want to check that any new errors actually were false negatives.

[cdce8p]

This release will fix many false negatives in an internal codebase I'm using for testing. This is great, but it slows down the testing process, since I want to check that any new errors actually were false negatives.

@JukkaL Not sure if it might you help but a while ago I started to uploading compiled dev builds to PyPI. They are stable enough that we even use these in day-to-day testing and CI. It has helped immensely to limit the changeset from version to version and made detecting actual regressions easier.

https://pypi.org/project/mypy-dev/
https://github.com/cdce8p/mypy-dev

[JukkaL]

Our internal mypy runner scripts can download wheels from mypy_mypyc-wheels, so testing them is already fairly easy (but it's still manual). I think I'll spot check new errors generated by PRs known to fix false negatives, and will carefully scrutinize new errors caused by other PRs only.

[JukkaL]

I'm looking into fixing (at least partially) this performance issue before cutting the release branch:

• Slow typechecking on nested TypedDict with union members #17231

[cdce8p]

I feel good about the odds that our 3.13 build stack is ready for us by the time we release 1.12.

It was announced a few hours ago that the 3.13 release would be delayed by a week and we'll get another release candidate on Monday instead. It depends when the next cibuildwheels release will be but we might even be able to have a 3.13 compatible version out before the actual release 🤞🏻

https://discuss.python.org/t/incremental-gc-and-pushing-back-the-3-13-0-release/65285

[JukkaL]

The performance issue I mentioned above (#17231) takes a bit more effort than I initially thought, so a full fix likely won't make into the release.

I've been testing mypy with an internal codebase, and there seem to be some regressions that I need to investigate more. #17427 seems to expose some bugs related to edge cases in mypy's union type implementation, as it increases the number of inferred union types. So far I have seen no evidence that #17427 itself misbehaves.

[JukkaL]

It looks like we can have 3.13 support in this release! A new version of cibuildwheel was just released, and it supports 3.13.0rc3: pypa/cibuildwheel@f185952

I'm still investigating one potential small regression.

[cdce8p]

It looks like we can have 3.13 support in this release! A new version of cibuildwheel was just released, and it supports 3.13.0rc3: pypa/cibuildwheel@f185952

We started building wheels for 3.13 yesterday. See mypyc/mypy_mypyc-wheels#82 :)

I'm still investigating one potential small regression.

With cibuildwheel?

[JukkaL]

We also need documentation for the recently merged TypedDict ReadOnly support (#17644). It doesn't block cutting the release branch, as it can be cherry-picked.

One more thing: I'd like mypy to generate an error when using the new syntax for type parameter defaults, since it looks like we won't have support for this yet in this release.

With cibuildwheel?

No, a new error which may be a false positive (I haven't created an issue for it yet).

[JukkaL]

I've created the release branch. ETA for the release is by Oct 11, assuming no major regressions are found.

[ilevkivskyi]

Btw @JukkaL should we announce in the release blog post that support for 3.8 will be dropped in the next release? See #17492

[ilevkivskyi]

As a suggestion, it may be worth cherry-picking #17883. It is not a new bug, but it is quite nasty and I bet a good chunk of existing daemon issues were caused by this.

[JukkaL]

I cherry-picked #17883. I agree that this is an important fix.

[JukkaL]

Additional cherry-picks:

• Add Python 3.13 to classifiers #17891
• Add changelog for mypy 1.12 #17889

[hauntsaninja]

#17898 will fix #17556 and #17659

I closed #17569 as "as designed" and not really relevant to functools.partial (existing mypy behaviour, we get errors now that functools.partial is actually checked). I closed #17297 as a duplicate

#17585 is not a regression (older mypy handles the case the same), but is a missing feature. Same deal with #17620, Ivan had suggestion on how to fix the false negative that I linked in the issue.

If you wanted to look at something, it could be interesting to look at #17741 or #17620

[JukkaL]

Cherry-pick:

• Improvements to functools.partial of types #17898

[JukkaL]

Documentation cherry-pick:

• documentation for TypeIs #17821

[JukkaL]

This should be fixed before the release is out:

• ReadOnly TypedDict items should be treated as covariant #17901

I'll look into this tomorrow.

[mr-c]

@JukkaL Not urgent, but could you also cherry-pick #17882 ?

• Include CHANGELOG.md in sdists #17882

[JukkaL]

Cherry-pick:

• Include CHANGELOG.md in sdists #17882

[JukkaL]

I will cherry-pick this fix to ReadOnly once merged:

• Make ReadOnly TypedDict items covariant #17904

[JukkaL]

More cherry-picks:

• Make ReadOnly TypedDict items covariant #17904
• Document ReadOnly (PEP 705) #17905

[ilevkivskyi]

@JukkaL I left a comment on #17551. This is not really a regression, it now "correctly" exposes an old bug. I will try to work on #17411 today/tomorrow.

[JukkaL]

This is not really a regression, it now "correctly" exposes an old bug.

Thanks for looking into this! We don't need to block the release on this, but it will okay to include a fix in a point release (if the fix is simple enough).

[JukkaL]

Another cherry-pick:

• Fix union callees with functools.partial #17903

[JukkaL]

Cherry-pick:

• Add latest 1.12 changes to changelog #17921

My current plan is to publish the release on Monday. We can still cherry-pick low-risk fixes until Monday morning (UTC).

[JukkaL]

Final cherry-picked fix before the release:

• Better handling of generic functions in partial plugin #17925

I'm now waiting for the final 1.12.0 wheels to build.

[JukkaL]

Mypy 1.12 is now out: https://mypy-lang.blogspot.com/2024/10/mypy-112-released.html

[ilevkivskyi]

It looks like the new syntax f[...](...) confuses markdown parser in the blogspot post. The very first line of the example is rendered incorrectly as a link, this is how I see it.

[JukkaL]

Fixed the example.

[hauntsaninja]

We've had a few regressions reported so far:

• [1.12 regression] False positive when iterating over union #17945
  • Use kw-only args for member access booleans #17975
  • Fix iteration over union (when self type is involved) #17976
• [1.12 regression] New error on type[memoryView] | type[str] #17942
  • Fix type object with type var default in union context #17991
• Issues with solving value constrained type var in presence of Any #17952
  • Restore os.path methods overload workaround typeshed#12837
• [1.11 regression] Infinite recursion with callables and follow imports skip #17954
  • Fix crash when showing partially analyzed type in error message #17961
• [1.12 regression] functools.partial and ParamSpec #17960

For cherry picks, it would be great to get this out:

• Significantly speed up file handling error paths #17920 (it makes mypy 1.5x faster in my work environment)

Less urgent than that one, but would also be nice to release these other perf wins:

• Use fast path in modulefinder more often #17950 (1.06x win)
• Let mypyc optimise os.path.join #17949 (1.10x win in my work environment)
• Use sha1 for hashing #17953 (1.005x win)
• Make is_sub_path faster #17962 (1.04x win in my work environment)
• Use orjson instead of json, when available #17955 / Add faster-cache extra, test in CI #17978
• Speed up stubs suggestions #17965

[hauntsaninja]

We now have fixes for 3/5 regressions, so it's worth making a release. I'd also like to release the performance improvements that target my work environment.

I could release those in a 1.12.1, but it feels a little out of line with what we traditionally release in patches, e.g. we have a new extra for using orjson, if the optimisations are buggy it feels sketchy to introduce them in a patch, etc

Options:

• I can make a 1.12.1 that has just the regression fixes
• I can make a 1.12.1 that has just the regression fixes + perf improvements
• I can do that, but just call it 1.13 (i.e. base it off the 1.12 branch) <-- option I'm leaning towards
• I just wait till actual next release

[JukkaL]

My preference would be to make a 1.12.1 with just the regression fixes first. We could then make 1.13 based on the 1.12 branch with perf improvements, or wait for the next normal release (either way works for me). My reasoning is that several regressions were reported soon after the release, so making a pure bugfix release seems like a good thing to do.

[JukkaL]

Fix to another regression:

• Fix type object with type var default in union context #17991

[hauntsaninja]

I cherrypicked the existing patches to the 1.12 branch and opened #17995 for the typeshed revert on 1.12 (reverted on mypy master in #17988)

[hauntsaninja]

I'll cut a 1.12.1 and a 1.13.0 in the next few days!

[mr-c]

I'm very glad for 1.12.1 to be released with fixes for the regressions, but on behalf of the maintainers of the over 250,000 repositories that use mypy, please don't release 1.13 right away.

https://github.com/python/mypy/network/dependents

Users who want the bleeding edge can instead depend on https://github.com/cdce8p/mypy-dev / https://pypi.org/project/mypy-dev/

As a compromise, you can make a pre-release of 1.13.0 to PyPI and on GitHub. That will be ignored by Dependabot (and perhaps other auto-updaters), but still be available for installing by those who wish to opt-in.

(None of the above is said with my Debian hat on. If a pre-release of 1.13 is made I will update the Debian package to use it)

[hauntsaninja]

I will be releasing a 1.13. I got into contributing to mypy because mypy makes my life better, it feels silly to be sitting on unreleased patches that make mypy 2.2x faster in the environment I use mypy in most often, and probably 10%-15% faster for many users.

Like I said above, 1.13 will just be cherry picks on top of 1.12.1 and not include type checking related changes, so hopefully it should be fairly smooth! — likely smoother than 1.12.0 -> 1.12.1 which will affect type checking. If you have a specific concern, we can figure out if there's a way to mitigate it. I'm not sure a pre-release makes sense if we don't have an actual release corresponding to that pre-release / it's unclear to me what problem it solves.

[hauntsaninja]

1.12.1 is out.

https://github.com/python/mypy/tree/release-1.13 is the branch for 1.13. #18000 is changelog PR. I'm planning on release 1.13 on Monday (pending any discussion in this thread)

[DanielNoord]

As somebody involved in updating dependencies within my company and some of those packages, please keep releasing like this.

It is silly to recommend work arounds to update to new versions as it only increases the amount of work needed to do dependency updates (for example, when do I switch back of the main repository). Besides, releasing often means that releases are smaller and investigating regressions is easier.

I understand that for distribution maintainers the situation is slightly different as they don't have Dependabot and friends, but packages that depend on mypy and have some sort of automatic updates set up (which many platforms offer free of charge to OS packages) would likely benefit from frequent smaller releases than one big breaking release.

Due to the importance of mypy in daily developer workflows (we're all waiting on CI) I actually find myself eagerly checking release tracking issues as almost every release has something that unblocks one of my colleagues. Having less frequent releases would only hurt me and those dependent on the updates I do.