Repository navigation
Release 1.0 planning #13685
Description
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
UnpackandTypeVarTupleas possible @jhance - Enable recursive types by default @ilevkivskyi
- Make
implicit_optionaloff 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-packagesthe 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-typesenabled by default (if fallout is not bad)
Activity
hauntsaninja commentedon Sep 19, 2022
I wasn't able to access. I requested access from
hauntsaninja at gmail dot comJelleZijlstra commentedon Sep 19, 2022
Same for me ([email protected]).
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 commentedon Sep 20, 2022
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 commentedon Sep 20, 2022
That's 9am Pacific.
JelleZijlstra commentedon Sep 26, 2022
The Zoom link asks for a passcode that I don't have.
ilevkivskyi commentedon Sep 26, 2022
Hm, weird, can you try
466977?ilevkivskyi commentedon Sep 26, 2022
Are you clicking on the Zoom link above? It includes the password.
AlexWaygood commentedon Sep 26, 2022
That works, but you need to let us out of the waiting room ;)
hauntsaninja commentedon Sep 26, 2022
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 commentedon Sep 27, 2022
I just merged
--no-implicit-optionaland--namespace-packages. Will add the suggestion for the--no-implicit-optionalcodemod now.One other change to get in for 1.0 we didn't mention: show error codes by default #13542
ilevkivskyi commentedon Sep 27, 2022
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 commentedon Sep 27, 2022
FWIW I like this idea, @JukkaL what do you think?
JukkaL commentedon Sep 27, 2022
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.
39 remaining items
hauntsaninja commentedon Feb 7, 2023
Here's a list of reported issues thus far, in priority order, that would be worth fixing in a patch release:
ilevkivskyi commentedon Feb 8, 2023
I can look at the first and the third later this week (If no one else does it before).
hauntsaninja commentedon Feb 8, 2023
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 commentedon Feb 8, 2023
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 commentedon Feb 9, 2023
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 commentedon Feb 9, 2023
#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_transformat all. In version 1.0, mypy now has some understanding ofdataclass_transform, just not an understanding that's quite sophisticated enough for the code in #14629.wesleywright commentedon Feb 9, 2023
#14580 will also cause new false-negatives and false-positives because
field_specifiersis 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 commentedon Feb 9, 2023
+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 commentedon Feb 13, 2023
Another potential PR to cherry-pick (very safe since this is a test-only change):
ilinum commentedon Feb 16, 2023
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 commentedon Feb 17, 2023
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).
Update to mypy 1
Update to mypy 1