Release 1.0 planning

[ilevkivskyi]

It is decided to release mypy 1.0 in ~two months, as mypy is mature enough for such a milestone. We need to plan this well in advance, so I am already opening this issue.

The result of some preliminary discussions is captured in this doc (please let me know if you have access issues). I would propose to have a Zoom call on Monday Sep 26 afternoon Dublin time (unless there are objections) to discuss the release plans in more details.

If you have any comments, questions, ideas, please leave them here (note we will still have 0.990 release between 0.980 and 1.0).

cc @JukkaL @jhance @JelleZijlstra @hauntsaninja @AlexWaygood @Michael0x2a @sobolevn @ethanhs @ilinum @svalentin (also please tag anyone I forgot here)

Tasks

More important things (in arbitrary order):

• Fix more crash bugs (everyone)
• Give an error if annotated variable appears in un-annotated function (with an error code to opt-out)
• Safe handling of empty bodies (with a flag to opt-out, + new error codes) @ilevkivskyi
• Split --enable-incomplete-features
• Implement as much of Unpack and TypeVarTuple as possible @jhance
• Enable recursive types by default @ilevkivskyi
• Make implicit_optional off by default (with a code transform tool to fix existing annotations) @hauntsaninja
• Detect unbound variables @ilinum
• Use unions for ternary joins @JelleZijlstra
• Full support for non-typing 3.11 features, see Python 3.11 tracking issue #12840
• Support as many typing 3.11 features as we can (including Enum)
• Make --namespace-packages the default @hauntsaninja
• Allow/disallow PEP 561 packages @ethanhs

Less important things:

• Support default value of generic parameter
• Always narrow types (see Types not added to binder on initial assignment #2008)
• Fix lost narrowing in inner functions
• Make --local-partial-types enabled by default (if fallout is not bad)

[hauntsaninja]

I wasn't able to access. I requested access from hauntsaninja at gmail dot com

[JelleZijlstra]

Same for me (jelle.ziijlstra@gmail.com).

I think the biggest risk here is that we commit to too many things before 1.0 and end up not releasing anything for a long time. That's bad for users because it means the improvements that do make it into master won't get to users. So I'm wary of committing to too many things that must be done before 1.0.

[ilevkivskyi]

I didn't see any objections, so here is a Zoom link I scheduled for Monday, Sep 26, 5PM Dublin time.

(I also added access to the doc for everyone who requested, let me know if it still doesn't work for some people)

[JukkaL]

I scheduled for Monday, Sep 26, 5PM Dublin time.

That's 9am Pacific.

[JelleZijlstra]

The Zoom link asks for a passcode that I don't have.

[ilevkivskyi]

Hm, weird, can you try 466977?

[ilevkivskyi]

Are you clicking on the Zoom link above? It includes the password.

[AlexWaygood]

Hm, weird, can you try 466977?

That works, but you need to let us out of the waiting room ;)

[hauntsaninja]

Btw, one thing we didn't discuss is documentation.
I've been making a series of docs PRs linked to this issue: #13681
If anyone has docs requests or suggestions, chime in there!

[hauntsaninja]

I just merged --no-implicit-optional and --namespace-packages. Will add the suggestion for the --no-implicit-optional codemod now.

One other change to get in for 1.0 we didn't mention: show error codes by default #13542

[ilevkivskyi]

Btw we forgot to discuss one idea in the meeting: how do people feel about having separate versioning for plugin API? Like every time we have a breaking change, we bump the plugin API version, so that plugin authors can check it and give a better error message instead of crashing.

[ilevkivskyi]

One other change to get in for 1.0 we didn't mention: show error codes by default #13542

FWIW I like this idea, @JukkaL what do you think?

[JukkaL]

FWIW I like this idea, @JukkaL what do you think?

Showing error codes by default sounds good to me. We probably still give the misc error code too often still, and we may want to switch some of them to non-misc error codes. At least the most common messages probably have reasonable error codes already, so the breakage from tweaking error codes in the future is probably acceptable.

[cdce8p]

It might make sense to change the default branch name to main, now that most repos in the python space are doing so as well (e.g. cpython, typeshed and others). Opened #13985 with more details.

[ilevkivskyi]

It looks like 1.0 is coming closer and closer. I think we should aim to release 1.0 in first half of December. Overall it looks quite good in terms of 3.11 support and fixing crashes and top bugs. Few questions:

• @ethanhs Do you think you will have time to work on allowing/disallowing PEP 561 packages?
• @JelleZijlstra Do you still want to implement the switch from join to union in ternary expressions?
• @sobolevn Will you have time to finish the LiteralString support?

Thanks!

[sobolevn]

Yes!

Side question: during the last meeting we decided to have some regular calls.
What do you think about pre-holidays post-release chat and small zoom party? ;)
Should I organize it? (Upvote this post if you like this idea)

[JelleZijlstra]

* @JelleZijlstra Do you still want to implement the switch from join to union in ternary expressions?

I think it should be done but I probably won't have time to work on it.

[yedpodtrzitko]

hi,
is there any plan to fix #10768 or eventually address #10600 in 1.0?

[ilevkivskyi]

I think there are no specific plans on these.

[ethanhs]

@ethanhs Do you think you will have time to work on allowing/disallowing PEP 561 packages?

I will try to work on this tomorrow/this weekend. If I don't get to it then, I probably will not have time to work on it for a while.

[ilevkivskyi]

@Michael0x2a It is almost December, so to be able to release mypy before holidays, I think you should start working on internal mypy pin move at Dropbox now (if you didn't already). This may discover some bugs/regressions that we will need to fix. Also please feel free to assign me to any issue caused by one of my PRs (but even if it is not my, I can still take a look).

[JukkaL]

I wouldn't include dataclass_transform in 1.0, since the implementation is still incomplete and we haven't had much time to play around with it.

The bug fixes seem good to include. Also fixing #14565 would be nice but I agree that we don't need to block the release on it.

[JukkaL]

I'll try to have a look at #14150 soon to decide if we should include it in 1.0. I'm on the fence about including it at the last minute, since it's quite a big change, but on the other hand if we'd have it, the overall performance improvement in 1.0 would be more impressive.

[hauntsaninja]

I just cherry picked a bunch of docs changes onto the release branch (and one testing change)

[ilinum]

We believe we have all of the necessary changes in the release-1.0 branch (speak now if you know that's not the case). We'll aim to release early next week.

[ilinum]

mypy 1.0.0 has been released (blog post)!

If we need to do any point releases for bugfixes, I will announce it on this issue.

[JohnVillalovos]

Just tried it and ran it and got an error when I tried it on the python-gitlab project:

python-gitlab/python-gitlab#2481

Logfile: https://github.com/python-gitlab/python-gitlab/actions/runs/4107691730/jobs/7087478909

.tox/mypy/lib64/python3.10/site-packages/mypy/typeshed/stdlib/unittest/mock.pyi: error: Source file found twice under different module names: "unittest.mock" and "mypy.typeshed.stdlib.unittest.mock"
Found 1 error in 1 file (errors prevented further checking)

[hauntsaninja]

@JohnVillalovos thanks for the report. Please report any problems you encounter in new issues.

With that said, your issue isn't anything to do with mypy 1.0.
It's caused by broken code in a third party package you use getsentry/responses#560 that was exposed by the change to always enable namespace packages in mypy 0.991. Please upgrade to responses>=0.22.0.

[intgr]

Ping @ymyzk, please add to mypy-play.net :)

[ymyzk]

Thanks for the heads-up, @intgr. mypy-play.net now supports mypy 1.0.0

Congratulations to everyone who made the 1.0.0 release possible. 🎉

[hauntsaninja]

Here's a list of reported issues thus far, in priority order, that would be worth fixing in a patch release:

• "unresolved placeholder type None" on mypy 1.0.0 #14631 (crash regression in 1.0)
• Regression on i686: testI64Cast fails (mypy v1.0.0) #14633 (mypyc test failure)
• Generic typeddict may corrupt the cache #14638 (present in 0.991 as well)
• Reusing variable previously defined with walrus operator triggers used-before-def error #14626
• Different behaviour of 1.0.0 wheels from pypi #14653 (regression to a plugin, but only when using mypyc-compiled mypy)

[ilevkivskyi]

I can look at the first and the third later this week (If no one else does it before).

[hauntsaninja]

I looked at the first, should be an easy fix (on the lines of some other fix you made recently)

Edit: PR here #14642

[ilinum]

Reopening for the bugfix release. I think we should wait a few more days in case more bugs surface.

I've sent out the PR #14646 to fix the used-before-def issue above.

[ilinum]

Is #14580 something we want to cherry-pick (given that it fixes a regression -- #14629)? That PR is pretty big, so it's unclear to me if it's worth fixing this issue considering the risk of new errors from a large PR.

[AlexWaygood]

#14629 is a regression in the "user experience" of mypy, in that mypy now emits a false-positive error on code where it previously didn't. But strictly speaking this speaks to the absence of a feature in mypy 1.0, rather than a regression in mypy's functionality. The reason why mypy now emits an error on that code when it didn't previously is because mypy previously had no understanding of dataclass_transform at all. In version 1.0, mypy now has some understanding of dataclass_transform, just not an understanding that's quite sophisticated enough for the code in #14629.

[wesleywright]

#14580 will also cause new false-negatives and false-positives because field_specifiers is not yet implemented. I'm working on that now, but these are big, featureful changes so I'm not sure whether they're fitting for a fix release (and also not sure how they would align with this timeline).

[hauntsaninja]

+1, we should not cherry pick it. Note that while #14629 has a new error, overall mypy 1.0 will complain less about the code in their example (e.g. mypy will let them instantiate their objects now)

[JukkaL]

Another potential PR to cherry-pick (very safe since this is a test-only change):

• [mypyc] Fix test case testI64Cast on 32-bit architectures #14691

[ilinum]

Looks like most of the important fixes are in and cherry-picked to release-1.0 branch. I'll make a 1.0.1 release tomorrow, unless anyone objects.

[ilinum]

mypy 1.0.1 has been released with the latest commit from release-1.0 branch!

Going to close this issue and will reopen if we need to do another point release (although hopefully not :P).