search

python-qt-tools / PyQt5-stubs

Stubs for PyQt5
GNU General Public License v3.0
69 stars 31 forks source link

mypy==0.991 #202

Open altendky opened 1 year ago

bluebird75 commented 1 year ago

This version of mypy is not released for Python 3.6 . So we need to add a conditional, one way or the other...

Apart from that, we can also search which was the first version that was broken by our stubs. I don't have much time right now for this, though.

altendky commented 1 year ago

Locally here in Linux, 0.940 is the first version to SIGSEGV. With 0.960 through 0.991 I get a few messages first but then they also SIGSEGV. https://github.com/python/mypy/commit/a9c62c5f82f34a923b8117a5394983aefce37b63 acts similar to 0.991. There are messages followed by a SIGSEGV, though there's an additional message. See https://github.com/python/mypy/issues/14196.

bluebird75 commented 1 year ago

I am convinced that we should have a very stable mypy for our tests, and one CI job with failure allowed for testing latest mypy.

Until this is fixed, 0.930 is our good version then.

altendky commented 1 year ago

Dependabot style automatic PRs are an alternative to consider instead of having 'latest version' jobs. But, there are upsides to all of various approaches to this.

Reported the segfault upstream. https://www.riverbankcomputing.com/pipermail/pyqt/2022-November/045068.html I'll take a look at a stubtest wrapper that monkey patches to disable the class finality test.

altendky commented 1 year ago

segfaults gone... now just 2853 regular stubtest errors. Hopefully my comments around the dependency versions in setup.py are sufficient to have a clue about what we're stuck on here.

bluebird75 commented 1 year ago

At least it passes with Python 3.6

altendky commented 1 year ago

Note that there's mypy 1.0 now as well. Depending, it may be better to work this intermediate step, or may be better to just get to 1.0 directly.