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?