Bug: mypy cannot access QMainWindow methods from MainWindow

[adam-grant-hendry]

__init__.py imports MainWindow from plotting. However, MainWindow is fully exported from window, not plotting. While not incorrect python, this causes mypy to not be able to see QMainWindow super class methods when creating pyvistaqt.MainWindow instances.

e.g.

from pyvistaqt import MainWindow

window = MainWindow()
window.setWindowTitle('window')  # mypy complains window has no attribute "setWindowTitle"

Also mypy<=0.961 does not yet fully support conditional imports (see Issue 1297 and 1393).

The fix for the first item is to either use a package wildcard import or import from the appropriate modules using the from ... import ... as ... notation:

Option 1: Explicit

...
else:
    from .plotting import (
        BackgroundPlotter as BackgroundPlotter,
        MultiPlotter as MultiPlotter,
        QtInteractor as QtInteractor,
    )
    from .window import MainWindow as MainWindow

Option 2: Implicit

...
else:
    from .plotting import *
    from .window import *

The fix for the second item would simply be to raise the RuntimeError directly within the except clause and use the @cjerdonek workaround:

try:
    from qtpy import QtCore as _QtCore
except Exception as exc:
    QtCore = None  # pylint: disable=invalid-name
    raise RuntimeError(f'No Qt binding was found, got: {exc}') from exc
else:
    QtCore = _QtCore
    # Do imports from ``plotting`` and ``window`` here

NOTE: PEP 484 states

• Modules and variables imported into the stub are not considered exported from the stub unless the import uses the import ... as ... form or the equivalent from ... import ... as ... form. (UPDATE: To clarify, the intention here is that only names imported using the form X as X will be exported, i.e. the name before and after as must be the same.)

• However, as an exception to the previous bullet, all objects imported into a stub using from ... import * are considered exported. (This makes it easier to re-export all objects from a given module that may vary by Python version.)

and Pyright indicates

If a file init.py uses the form “from .A import X”, symbol “A” is not private unless the name begins with an underscore (but “X” is still private).

A module can expose an all symbol at the module level that provides a list of names that are considered part of the interface. The all symbol indicates which symbols are included in a wildcard import.

Note also that Pyright states

• import A as A is called a redundant module alias
• from X import A as A is called a redundant symbol alias