Define some constants for pyright to control how it handles the imports
in qutebrowser.qt.*
This is mainly for autocompletion and definitions with VS Code, which
uses pyright via the pylance extension. If you have multiple possible
places something could be imported from, and one of them isn't
installed, the type of the thing being imported will fall back to Any,
and you wont get nice things.
So we use this file to make sure only certain imports are configured.
The most important thing to remember about this file is it'll control
where type definitions come from in VS Code. You can have multiple
backends defined as true, generally the last import will win in that
case. If any of the enabled imports aren't installed though you may not
get any type hints at all.
PyQt5 has been configured for now to match the type checking configured
in CI.
Personally I would be fine with PyQt6 configured here anyway since
that's generally what we are developing against these days.
See #7370 for more info.
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 1bbf75ae7d.
(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 c1738ca550.
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 c1738ca550.
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.
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.
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.
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.
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
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.
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.
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
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.
toofar
Florian Bruhin