1.19 Release Planning

[ilevkivskyi]

We always wanted to release more often. I would propose to already aim at 1.19 release mid or late October.

cc @JukkaL

[ilevkivskyi]

From my side I would propose to:

• Stop calling --fixed-format-cache experimental
• Expose it in argparse on interpreted mypy (since we can now)
• Announce that --fixed-format-cache will be default in 1.20

[wyattscarpenter]

If https://github.com/python/mypy/issues/19922 (keep more readthedocs versions around) has to be done prospectively, it would be nice to enable that setting(?) on readthedocs before the next release. If old versions can easily be made retroactivity, however, this doesn't matter.

[ilevkivskyi]

Btw it may be worth highlighting https://github.com/python/mypy/pull/19719 in the release blog post, it is a surprisingly popular request.

[sterliakov]

[x] (resolved) Upgrading 1.18.2 to 1.19.0 cannot be performed with pip install -U. Am I missing any workarounds? If not, #20006 should probably be ALL CAPS and bold in the release notes.

[JukkaL]

Mid to late October release sounds good. @p-sawicki is expected to be the release manager.

This release will also have librt as a new dependency. It would be good to test installation in different contexts before the release goes out.

This is a release blocker (I'm working on it but have been busy recently, so not much progress):

• mypyc/mypyc#1141

It would be nice to have free-threaded binary wheels for 3.14 (3.14t). Currently free-threaded builds use the interpreted version of mypy.

Upgrading 1.18.2 to 1.19.0 cannot be performed with pip install -U. Am I missing any workarounds?

We haven't released 1.19.0 yet. Not being able to install a release using pip install -U is a release blocker.

[sterliakov]

We haven't released 1.19.0 yet

Yep, sorry, I was trying to say that if 1.19.0 were released from current master branch, pip install -U would silently produce a broken installation.

[BobTheBuidler]

I'm hoping to get some of these mypyc optimizations merged in. I know I've made quite a few PRs lately so this little blurb should help separate signal from noise and make the review process easier from your end.

I'd like to get #19982 merged in so I can rebase and get the tests working for #19984 . They're both pretty straightforward.

I'm hoping to get some or all of these length helpers merged in so I can rebase the others and put them all to bed, they're all related but I kept them separate to avoid cluttering up the diff. I know there will be minor conflicts for me to deal with:

• #19930
• #19929
• #19927

And these 4 standalone ones are all ready and should all be relatively straightforward to review

• #19883
• #19972 - 6 LOC
• #19673 - you looked at this one already and just wanted some benchmark data
• #19643 - you looked at this one before releasing 1.18, there's just one open question left to close it out

Mypyc is evolving at a nice pace, love to see it. It's pretty exciting to watch you guys cook on the librt stuff. I can't say I understand how it all fits together but I'm excited to see some live examples and start hacking!

[randolf-scholz]

Hey, I have a bunch of open pull requests, hope that maybe some of them can make it into the next release.

• #19449
• #19466
• #19471
• #19517
• #19897

and there's also #19046, but I think @sterliakov wanted to see a few more tests in this one.

[Chainfire]

I am excited about a new update, it would be great to have an official release that actually builds and runs our code (as there has never been one). However, running our test suite against the latest commit in master, I'm seeing segmentation faults and type errors all over the place. I'll see if I can hunt them down (may well be user error, badly typed mocks, etc) I guess...

EDIT (3):

• Some segfaults have been cleared by consistently force removing the build directory and all .so files generated before rebuilding. While fair, this was not necessary on 1.17.0 for the same patterns. But have more segfaults not solved by this.
• TypeErrors now seem limited to traits with async methods.

The mentions listed below are what I have thus far against mypy 1.19.0+dev.2c6c3959356674262d9b2c2dc43a33486e807a9. I'm a little on the fence about thinking something is wrong with my installation, but I wouldn't know what. I've reset and resynced the entire repo, force reinstalled librt, installed locally, and ./runtests.py to completion without any other errors.

[BobTheBuidler]

I have 2 more bug fixes ready for 1.19

• #20085
• #19957 - This one was working, I broke it, and now there's just one open question about how allow_interpreted_subclasses interacts with native_class and @final I can finish it up for 1.19 with some small feedback

[ilevkivskyi]

I tried MYPY_USE_MYPYC=1 pip install -U . locally on current master, and after install I am getting:

Traceback (most recent call last):
  File "/home/ivan/venvs/mypy_dev_3_12/bin/mypy", line 5, in <module>
    from mypy.__main__ import console_entry
ImportError: /home/ivan/venvs/mypy_dev_3_12/lib/python3.12/site-packages/7ae574991b77ef47acad__mypyc.cpython-312-x86_64-linux-gnu.so: undefined symbol: CPyTagged_BitLength

cc @BobTheBuidler it looks like this may be caused by your recent PR. Are you able to build/install mypy locally? Fixing this is a release blocker.

[ilevkivskyi]

Hm, actually reverting that commit doesn't fix the problem for me, I get a different error

Traceback (most recent call last):
  File "/home/ivan/venvs/mypy_dev_3_12/bin/mypy", line 5, in <module>
    from mypy.__main__ import console_entry
ImportError: /home/ivan/venvs/mypy_dev_3_12/lib/python3.12/site-packages/7ae574991b77ef47acad__mypyc.cpython-312-x86_64-linux-gnu.so: undefined symbol: CPyStr_EqualLiteral

probably something else is broken.

[ilevkivskyi]

Actually nvm, rm -rf build dist fixed the problem. That said it looks like there is some kind of caching bug in pip install, bit probably not a big deal.

[BobTheBuidler]

I hate to throw a bunch of stuff at you at once (hehehe just kidding...) but here's one more fix, this time for a condition that causes mypyc to crash

• #20098

#20098 is part of a larger #20100 , so I separated them out to give you the option of merging the fix before spending any time revieing the feature

[Chainfire]

Another (for us, showstopper) issue above. I have uncovered another serious leak that I so far haven't been able to isolate further than task.cancel() on a task that has an add_done_callback() registered, but these may be the same issue as the one above, ultimately.

[hauntsaninja]

https://github.com/mypyc/mypyc/issues/1154 could be good to fix

[emmatyping]

I would recommend we make this version the last to support 3.9 see https://github.com/python/mypy/issues/20154

[JukkaL]

Found a release-blocker when testing in an internal repository:

• #20174

[ilevkivskyi]

@JukkaL are there any other blockers for the release? I think we should try getting it out, as it is already late.

[JukkaL]

I think all the blockers have been resolved, now that librt.internal versioning works better (#20221 and #20225).

[mr-c]

https://github.com/mypyc/mypyc/issues/1154 could be good to fix

I think this regression which makes black segfault is still very important

[JukkaL]

Ok, I'll look at https://github.com/mypyc/mypyc/issues/1154 soon.

[BobTheBuidler]

I can forget about some of the features for now if that's best for the maintainers but I'd definitely like to get both of these bug fixes into the 1.19 release. The first is already ready to roll, the 2nd has just one pending concern to resolve before its also merge-ready.

I have 2 more bug fixes ready for 1.19

• [mypyc] fix: UnboundLocalError incorrectly raised as AttributeError #20085
• [mypyc] fix: isinstance_native fast path conflict w/ interp. subclasses [1/1] #19957 - This one was working, I broke it, and now there's just one open question about how allow_interpreted_subclasses interacts with native_class and @Final I can finish it up for 1.19 with some small feedback

[ilevkivskyi]

@BobTheBuidler I would focus only on critical fixes as we already behind schedule.

[JukkaL]

Yeah, we will likely have another release in December or January.

[BobTheBuidler]

to be clear, without #19957 merged mypyc currently produces incorrect results for isinstance in some cases which imo is a pretty significant bug. I have some libraries that support Python3.9 which are impacted by this bug, so if 1.19 is going to be the last version that supports 3.9 its really important for me.

#20085 is less critical but is still a fix for a current case where mypyc behavior violates python semantics. I was under the impression that we want to eliminate these cases ASAP but we can kick that can down the road if you prefer.

[JukkaL]

Since we are late in the release process, we generally focus on critical fixes related to new functionality, and fixes to regressions. Other fixes can be merged as well, but they are lower priority. Otherwise releases tend to drag on for too long. #19957 seems pretty important and relatively small so we can try to get it in if the PR will be in a mergeable state in the next several days.

[BobTheBuidler]

Sounds good, I just have one quick open question for a maintainer on #19957 and I can get it fixed up straight away

[Chainfire]

I understand the need to focus on regressions, but does https://github.com/mypyc/mypyc/issues/1141 not count for that? It still breaks and used to work.

[JukkaL]

@Chainfire Yeah, https://github.com/mypyc/mypyc/issues/1141 seems important to fix -- I lost track that some cases are still broken. Thanks for the reminder!