summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-10-14doc: add some contributor notes about mypychore/docs_about_mypytoofar
also update the default tox env list which I forgot to do when changing the mypy targets.
2022-09-16mypy: Remove unneeded int(...)Florian Bruhin
Follow-up to 377bdf736f96605b998ca6f2ea2b062e190653b0 - less confusing that way IMHO, as the value now is already an int in that branch.
2022-09-16mypy: Make VENDORED_SIP privateFlorian Bruhin
Follow-up to 76ca4a9dd61e7179881044757d83d2bf5928819d.
2022-09-16mypy: Use cast instead of ignore for QKeySequenceFlorian Bruhin
Follow-up to 3d93e1537836e91580eae32714f440626a2a1e15
2022-09-16mypy: Use Union instead of ignoreFlorian Bruhin
2022-09-16mypy: Use annotation instead of assertFlorian Bruhin
Follow-up to 9c193c18f08f30c341e4869d5e84a4564a58afd1
2022-09-16mypy: Move around some commentsFlorian Bruhin
2022-09-16mypy: Make type for _PREFERRED_COLOR_SCHEME_DEFINITIONS more concreteFlorian Bruhin
Follow-up to b0e3dcef819d9e24361051d2dc85f6f0e8762aa6.
2022-09-16Drop certificateerror.create factory functionFlorian Bruhin
Now that the two implementations are in the same class, there's no need for the indirection anymore. Follow-up to 647b74197a779e00cae1847654796581df28a7b0.
2022-09-16mypy: Simplify handling in show_dialogFlorian Bruhin
The problem here is that mypy (correctly) complains that self._dialog could be None again at the point that the lambda runs, which is a different variable scope. The assert can be dropped (in the show_dialog locals scope, mypy *knows* it's never None, as we just assigned it!). Follow-up to 1bbf75ae7dbbfa2568bd5fe50dc1d7d213377f4e.
2022-09-16tox: Use more unique env var nameFlorian Bruhin
(Ab)using an environment variable indeed seems like the easiest way forward here, but since it is exposed in the environment for the called processes, let's give it a name which is less likely to clash, and more easily identifyable. Follow-up to c1738ca55006966e7c0ad9eacbfb58625aa88c44.
2022-09-16mypy: Use tox.ini to install PyQt6 conditionallyFlorian Bruhin
The changes in requirements-mypy.txt would get overwritten on the next dependency update. Also, it looks like we don't actually need PyQt6 (or the PyQt6 stubs) available for checking PyQt 5 code if all Qt 6 imports are appropriately gated by conditionals mypy knows about. Follow-up to c1738ca55006966e7c0ad9eacbfb58625aa88c44.
2022-09-16Document how to set the backend for the tests.toofar
I only had the old way save in my bash history and this one was only mentioned in the changelog. Also changed the heading above the new entry to be title case, which seems to be more consistent with the other headinfs in the file. Also remove the one remaining mention of `QUTE_BDD_WEBENGINE` since it does nothing anymore.
2022-09-16remove leftover compiled requirements filestoofar
Leftover from 62515fecf0a64f ref #7091
2022-09-16Merge pull request #7392 from qutebrowser/feat/turn_on_mypy_pyqt5toofar
Get mypy working, with pyqt5, on qt6-v2 branch
2022-09-11fix lint: qt5 vs qt6 confusionfeat/turn_on_mypy_pyqt5toofar
2022-09-11mypy: re-enable CI jobs for pyqt5toofar
We'll be going forward with type checking on PyQt5 for now while figuring out what to do with PyQt6 type checking. See https://github.com/qutebrowser/qutebrowser/discussions/7372#discussioncomment-3502200
2022-09-11mypy: fix qenum debug type hints?toofar
1. stop pretending to propagate None to the qt/python debug methods 2. handle simplewrapper in extract_enum_val I think this stuff will need a little more cleaning up when we get to sorting out type checking on PyQt6. The whole key debug module seems to be a bit fuzzy about when it's going to be passing around a simplewrapper, int and enum. I believe we are using sip.simplerwapper as a common parent type of all the Qt Flag/Enum values. I think it gets better on PyQt6, don't remember though. It might just change to be sip.wrapper instead.
2022-09-11mypy: add hints and comments around QKeySequencetoofar
Mypy doesn't seem to know that QKeySequence is an iterable, so it complains about itertools not handling it. And since we lose type information there we have to add it back in a couple of places.
2022-09-11mypy: defer to machinery for conditional: QKeyCombinationtoofar
That wasn't so hard, just put everything behind compile time constants, even the type definition.
2022-09-11mypy: ignores for another enum: KeyboardModifiertoofar
There are several cases where PyQt5 methods expects the plural flags version but we've got the singular Enum version from accessing enum members directly. It's not easy to turn those enums into flags and the flags don't even exist in PyQt6.
2022-09-11mypy: handle none case in Optional: downloads.replytoofar
I'm not sure how theoretical this case is. There is a comment somewhere else indicating the reply can "disappear".
2022-09-11mypy: add type hint for defs in darkmode.pytoofar
Not sure why mypy was failing to see the inner dicts in _PREFERRED_COLOR_SCHEME_DEFINITIONS where being seen as "object" by mypy and not dict, I think the syntax is correct. Add some basic type hints to help it. They Any is because usertype.UNSET() is a sentinal object
2022-09-11mypy: cast to subtype: WebEnginePrintingtoofar
2022-09-11mypy: defer to machinery for conditional: QWebEngineScriptstoofar
2022-09-11mypy: defer to machinery for conditional: printingtoofar
2022-09-11mypy: Add Optional hint to inspector._settingstoofar
2022-09-11mypy: defer to machinery for conditional: inspector APItoofar
2022-09-11mypy: defer to machinery for conditional: webview.certErrortoofar
2022-09-11mypy: access our tab_bar implementation, not tabBartoofar
Apparently this got changed by the scripts/dev/rewrite_enums.py script? Strange. 0877fb0d78635
2022-09-11mypy: ignore enum argument type: UrlFormattingOptiontoofar
The docs say: > The options from QUrl::ComponentFormattingOptions are also possible. > The FormattingOptions type is a typedef for QFlags<UrlFormattingOption>. It stores an OR combination of UrlFormattingOption values. Maybe we should be should be definining out own types for some of the enums that include both the QFlag, enum and any child enums.
2022-09-11mypy: add Optional hint to QPrintDialogtoofar
2022-09-11mypy: ignore enum binary operator: Qt.WindowTypetoofar
They are the same damn thing: https://doc.qt.io/qt-6/qt.html#WindowType-enum
2022-09-11mypy: fix exec() type hints?: prompttoofar
PyQt5 stubs require a flags object that doesn't exist in PyQt6
2022-09-11mypy: defer to machinery for conditional: QDownloadItemtoofar
2022-09-11mypy: ignore enum binary operator: UrlFormattingOptiontoofar
Yet another case of confusion between flags and enum objects.
2022-09-11mypy: fix KeyboardModifier type in webelem?toofar
Conditionally define a type so it can work with PyQt5s mismatch of enums and flags and PyQt6s enums.
2022-09-11mypy: defer to machinery for conditional: QOpenGLVersionProfiletoofar
2022-09-11mypy: defer to machinery for conditional: qWebEngineVersiontoofar
2022-09-11mypy: defer to machinery for conditional: QVarianttoofar
2022-09-11mypy: move conditionals for CertificateErrorWrapper into classtoofar
Get rid of the per-backend classes and move the backend specific conditionals into a common class. Sadly it seems mypy isn't clever enough to reason ignore a class it should know is never used. Possibly it looks at them at parse time. Probably putting the whole class definitions into conditionals would do it but I'm not sure if I want to go down that route for such a small example. Hopefully there aren't too many more of these.
2022-09-11mypy: defer to machinery for conditional: QtSql bound valuestoofar
Also turn the qt5 value into a list instead of a dict_values, for the sake of mypy
2022-09-11mypy: fallback sqlite error code can be strtoofar
2022-09-11mypy: defer to machinery for conditional: QLibraryInfotoofar
2022-09-11mypy: fix exec() type hints?toofar
PyQt5 exposes Enums and their corresponding QtFlags objects seperately, and for some reason they aren't interchangeable. ref https://github.com/python-qt-tools/PyQt5-stubs/issues/142 We could handle this by casting values back and forth between the enum value (for working with) and the flags value (for passing to methods), but this situation doesn't even exist with PyQt6, you can use everything as enums just fine. So I'm just adding ignore comments and making type definitions conditional. Not sure if this is the right thing to be doing or not. for b3cdb28d044
2022-09-11mypy: fix hints for abstract cert error wrappertoofar
2022-09-11mypy: handle sip conditional importstoofar
Putting ignore[type] on the second import works fine. But if we have it on both the pyqt5 and pyqt6 branch it'll complain about the other branch on each run. So pull it out to a common place we can ignore.
2022-09-11tox: split mypy env into mypy-{qt5,qt6}toofar
Would be nice to have a bare `mypy` env which ran both the more specific ones in sequence but I don't know how to do that. Not sure if there is a way to pull the CONSTANTS_ARGS stuff out to a non-env parameter and pass it into commands but I couldn't figure out a way. So via the environment it is. TODO: compare PyQt6 as-is with the WIP PyQt6-Stub
2022-09-10fix linttoofar
I prefer consistency of import over this complaint which doesn't even apply here (the conditionals are mutually exclusive).
2022-09-10Adjust import order in machinery for pyright/vscodetoofar
When pyright tags an object as "Unknown" (even if that is just one part of a union of possible definitions) then VS code doesn't provide autocompletion for that objects. Additionally, if you import that same object from multiple modules in a file pyright (or VS Code?) will go through them in order and prefer the last one. 1. if you import an object by name from two modules and that latter module isn't installed the object will be marked as "Unknown" if machinery.USE_PYQT5: # installed from PyQt5.QtWebEngineWidgets import QWebEngineHistory elif machinery.USE_PYSIDE2: # not installed from PySide2.QtWebEngineWidgets import QWebEngineHistory reveal_type(QWebEngineHistory) # class(QWebEngineHistory) | Unknown 2. if you import an object by name from a module that isn't installed and that module isn't later overridden it'll be marked as "Unknown" if machinery.USE_PYQT6: # installed from from PyQt6.QtWebEngineCore import * elif machinery.USE_PYQT5: # not installed from PyQt5.QtWebEngineWidgets import QWebEngineHistory reveal_type(QWebEngineHistory) # class(QWebEngineHistory) | Unknown if machinery.USE_PYQT5: # not installed from PyQt5.QtWebEngineWidgets import QWebEngineHistory elif machinery.USE_PYQT6: # installed from from PyQt6.QtWebEngineCore import * reveal_type(QWebEngineHistory) # class(QWebEngineHistory) So in general we want to put modules most likely to be installed at the bottom. Except if it imports an object by name and there is a possibility it won't be installed we want to bump it up. So now we have: 1. PySide6: not currently supported 2. PyQt5: main supported type checking language, but not guaranteed to be installed 3. PyQt6: quite likely to be installed but not yet supported for type checking This means that if you have both PyQt6 and PyQt5 installed you will get autocompletion from PyQt6. It might be better to get it from PyQt5 instead, since that's what we will be type checking with on CI for now, but getting no autocompletion because you only have PyQt6 installed and not PyQt5 is not ideal. You can confirm this by using the "go to definition" feature. Hopefully we can use the defineConstant configuration parameter for pyright to make this ordering less important in the future by using that to set the proffered bindings for type checking.
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion