Pyright/Pylance : Some types are potentially unknown

[Avasam]

This happens with all _ns_module.* types as far as I can tell, but here's an example from windows.graphics.directx.direct3d11.__init__.py:

Then in windows.graphics.capture.__init__.pyi

Which produces strict type-checking errors in my code, unless I explicitly specify the type:

Even though IDirect3DSurface is defined in windows.graphics.directx.direct3d11.__init__.pyi:

I don't think this is expected behavior from python-winsdk (it doesn't seem like it). Nor do I know why it's happening or how to fix it. I can raise an issue over at Pyright if you can't correct this issue and believe it's on their side.

[dlech]

It sounds like Pylance has changed since last time I used it (which was probably a few months ago). It is probably worth asking there how to handle "weird" imports like this. For example, are there some kind of comments or type hints we can add to tell it to only look at the .pyi files for certain modules?

There are also some typing fixes I haven't released yet - although I don't think they will help in this case.

[dlech]

I think I found the issue. winsdk.windows.graphics.capture imports winsdk.windows.ui.composition but this module isn't available for technical reasons. This is what introduces the Unknown to all of the typings in the file.

I think we can fix it by changing the imports to something like:

import winsdk.windows.foundation as _winsdk_windows_foundation

[dlech]

Probably could still be considered a bug in Pylance though.

[Avasam]

I can confirm that changing the import to import winsdk.windows.ui.composition as _winsdk_windows_ui_composition in the pyi file only and def create_from_visual(visual: _winsdk_windows_ui_composition.Visual) -> GraphicsCaptureItem: ... Does work as a fix

Unless you prefer doing so (I'm sure you have a better understanding of it than I do), I'll open an issue on pyright. It doesn't seem like it should do a difference and especially not propagate Unknowns everywhere. (only the visual parameter should be unknown)

[Avasam]

Even from winsdk.windows.ui import composition then composition.Visual seems to work (not sure if there's other side effects). I guess as long as you don't use winsdk.windows.ui.composition.<something> directly in the type definition.

Causes issues:

Ok?:

[dlech]

Let's see if we can get it fixed in Pyright first.

[Avasam]

https://github.com/microsoft/pyright/issues/3328#issuecomment-1097547290

https://github.com/microsoft/pyright/releases/tag/1.1.237

Bug Fix: Fixed bug that resulted in incorrect type evaluation when an import statement failed to resolve and targeted a submodule of a previous import statement, such as import a.b followed by import a.b.c where a.b.c couldn't be resolved. In this circumstance, pyright "forgot" that a.b had been resolved previously, so all symbols imported from a.b were evaluated as Unknown.