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)
• [x] Give an error if annotated variable appears in un-annotated function (with an error code to opt-out)
• [x] Safe handling of empty bodies (with a flag to opt-out, + new error codes) @ilevkivskyi
• [x] Split --enable-incomplete-features
• [ ] Implement as much of Unpack and TypeVarTuple as possible @jhance
• [x] Enable recursive types by default @ilevkivskyi
• [x] Make implicit_optional off by default (with a code transform tool to fix existing annotations) @hauntsaninja
• [x] Detect unbound variables @ilinum
• [ ] Use unions for ternary joins @JelleZijlstra
• [x] Full support for non-typing 3.11 features, see https://github.com/python/mypy/issues/12840
• [ ] Support as many typing 3.11 features as we can (including Enum)
• [x] 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 #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 ([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]

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: https://github.com/python/mypy/issues/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 https://github.com/python/mypy/pull/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 https://github.com/python/mypy/pull/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).

[hauntsaninja]

None of this is blocking, but here's some recent issues it might be nice to have fixes for:

• https://github.com/python/mypy/issues/14254
• https://github.com/python/mypy/issues/14250
• https://github.com/python/mypy/issues/13981
• https://github.com/python/mypy/issues/13850
• https://github.com/python/mypy/issues/14353

Here are some PRs we'd ideally ship:

• https://github.com/python/mypy/pull/14277
• https://github.com/python/mypy/pull/14274
• https://github.com/python/mypy/pull/13838

I'll hopefully have time for some of these next week if no one beats me to it.

[ilevkivskyi]

For those who is following here, we were not able to release this due to some delays, next target date is mid-January.

[ilevkivskyi]

In the meantime I will look at some of the crash bugs.

[JukkaL]

Release blocker:

• #14475 [done]

[JukkaL]

Regression (not necessarily a release blocker):

• #14476

[ilinum]

Two potential blockers:

• #14480
• #14481

[davidhalter]

I'm wondering if it would make sense to enable this one:

Make --local-partial-types enabled by default (if fallout is not bad)

It seems to be the only one that would break backwards compatibility after 1.0. What do you think?

[JukkaL]

I expect that --local-partial-types will cause a big fallout, so we'll postpone it to another release. We'll need to announce it ahead of time.

[intgr]

As a data point, I tested the latest 1.0 from mypy_mypyc-wheels on my mid-sized project. There are no regressions, only a few new reported errors that are accurate. --local-partial-types does not cause any additional errors in my project.