python
1.12/1.13 Release Tracking Issue
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?
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.
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.
For the later, we'd probably need to wait for cibuildwheel to be updated.
I was curious about this and found https://github.com/mypyc/mypy_mypyc-wheels/pull/82 which is failing against https://github.com/python/mypy/commit/5c38427a53f409bae068c314e119fecc77730d76 from September 16th.
Testing Python 3.13 mypy wheels won't work until Python 3.13.0 final (with the recently merged https://github.com/python/cpython/pull/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.
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?
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 :-)
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.
As of https://github.com/python/mypy/pull/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
I've been testing the latest master, and I've found one release blocker so far:
- https://github.com/python/mypy/issues/17841
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.
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
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.
I'm looking into fixing (at least partially) this performance issue before cutting the release branch:
- https://github.com/python/mypy/issues/17231
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
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.
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: https://github.com/pypa/cibuildwheel/commit/f1859528322d7b29d4493ee241a167807661dfb4
I'm still investigating one potential small regression.
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 https://github.com/mypyc/mypy_mypyc-wheels/pull/82 :)
I'm still investigating one potential small regression.
With cibuildwheel?
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).
I've created the release branch. ETA for the release is by Oct 11, assuming no major regressions are found.
Btw @JukkaL should we announce in the release blog post that support for 3.8 will be dropped in the next release? See https://github.com/python/mypy/pull/17492
As a suggestion, it may be worth cherry-picking https://github.com/python/mypy/pull/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.
There are various recent issues reported about functools.partial, which got improved support in mypy 1.11. I'll look at fixing some of these:
- https://github.com/python/mypy/pull/17297
- https://github.com/python/mypy/issues/17741
- https://github.com/python/mypy/issues/17659
- https://github.com/python/mypy/issues/17620
- https://github.com/python/mypy/issues/17585
- https://github.com/python/mypy/issues/17569
- https://github.com/python/mypy/issues/17556
- https://github.com/python/mypy/issues/17411
Any help is also appreciated! I'll assign myself when I start working on any of the above issues.
https://github.com/python/mypy/pull/17898 will fix https://github.com/python/mypy/issues/17556 and https://github.com/python/mypy/issues/17659
I closed https://github.com/python/mypy/issues/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 https://github.com/python/mypy/pull/17297 as a duplicate
https://github.com/python/mypy/issues/17585 is not a regression (older mypy handles the case the same), but is a missing feature. Same deal with https://github.com/python/mypy/issues/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 https://github.com/python/mypy/issues/17741 or https://github.com/python/mypy/issues/17620
This should be fixed before the release is out:
- #17901
I'll look into this tomorrow.
@JukkaL Not urgent, but could you also cherry-pick https://github.com/python/mypy/pull/17882 ?
- https://github.com/python/mypy/pull/17882