-
I have some code for which pyright is reporting an "unknown import symbol" in a third-party library that I can't figure out. It also involves conditional imports, and I found issue #1358 and tried to use TYPE_CHECKING to control which version of an import was included, and that solved another issue I was having. However, pyright is now returning an "unknown import symbol" error that I can't seem to avoid. I've stripped down the code to a bare minimum (just class declarations and imports) and I'm still able to reproduce the problem. I've got a base module and two platform-specific modules (unix and win32), plug a try...except meant to cover when the third-party library is not installed. It currently looks something like: gss.py: import sys
from typing import TYPE_CHECKING
try:
if sys.platform == 'win32':
from .gss_win32 import GSSBase, GSSClient, GSSServer, GSSError
else:
from .gss_unix import GSSBase, GSSClient, GSSServer, GSSError
gss_available = True
except ImportError:
gss_available = False
if not TYPE_CHECKING:
class GSSError(ValueError):
"""Stub class for reporting that GSS is not available"""
class GSSBase:
"""Base class for reporting that GSS is not available"""
class GSSClient(GSSBase):
"""Stub client class for reporting that GSS is not available"""
class GSSServer(GSSBase):
"""Stub client class for reporting that GSS is not available""" gss_unix.py:
gss_win32.py: class GSSBase:
"""GSS base class"""
class GSSClient(GSSBase):
"""GSS client"""
class GSSServer(GSSBase):
"""GSS server"""
class GSSError(Exception):
"""Class for reporting GSS errors""" The error I'm getting is:
I've also tried replacing the GSSError import in gss_unix.py with If it matters, the system I'm running this on has the gssapi package installed, and so the import from gss_unix.py should be succeeding and getting the definition of GSSError from gssapi.exceptions. I just noticed that GSSError appears to be defined in a C module in that package, so perhaps that's related. Without providing my own stubs for this module, is there some way I can silence this error? I'm fine if there's no type checking related to this class. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Thanks for posting. This is a bug in pyright's import resolution logic. In particular, it's related to the case where a chain of imports (where one module imports a symbol from another module, which imports it from another module, etc.) ends in a native library (a ".pyd" or ".so" binary file). Pyright should resolve this without errors and supply an "Unknown" type for the symbol. This will be fixed in the next release. |
Beta Was this translation helpful? Give feedback.
Thanks for posting. This is a bug in pyright's import resolution logic. In particular, it's related to the case where a chain of imports (where one module imports a symbol from another module, which imports it from another module, etc.) ends in a native library (a ".pyd" or ".so" binary file). Pyright should resolve this without errors and supply an "Unknown" type for the symbol. This will be fixed in the next release.