Merge upstream 5.15.3 - Githubissues

python-qt-tools / PyQt5-stubs

Stubs for PyQt5

GNU General Public License v3.0

66 stars 31 forks source link

Merge upstream 5.15.3 #138

Closed altendky closed 3 years ago

altendky commented 3 years ago

Draft for:

[x] Actually merging #137
[x] Update merge from the upstream branch to here
[x] Self review of the net changes.
[x] Tests passing
[x] Changelog entry

altendky commented 3 years ago

I'm not exactly sure how I feel about dropping testing for 3.5. But, we won't be getting 5.15.3 in 3.5 and we won't pass stubtest in both 5.15.3 and 5.15.2 (or probably really any two versions since some interface presumably changed). So, I'm not really sure what it would mean to support multiple versions. If it were a Python version issue you can do some amount of if sys.version_info >= (3, 7): and such. But for the PyQt version I think we would have to either make a plugin or use --always-true PYQT_5_15_2 or such and then our users would have to configure the same when running Mypy. And that doesn't start into stubtest either...

BryceBeagle commented 3 years ago

3.5 has reached EOL. I'm fine dropping support for it

The-Compiler commented 3 years ago

Do you know which PyPI package QtWebkit is in? I couldn't locate it

It's not on PyPI - given that it was removed from Qt 5.6 but still (barely) maintained independently, it's pretty much on "life support" in PyQt5. It only works when building PyQt5 from source with QtWebKit available (or when using distribution packages which do so).

It seems to be gone entirely in PyQt6 FWIW.

altendky commented 3 years ago

Huh, I wonder what's up with stubtest missing these. I thought it had caught such stuff. Thanks for the review, I'll see what I can figure out.

altendky commented 3 years ago

I guess it only catches stuff in the stubs that isn't in the runtime. The other way could be pretty noise I suppose. It's not like you want to hint the presence of sys or other misc 'not-exported' attributes in every stub etc.