pylint errors with no-name-in-module of globus_sdk version 3.47.0

[ddeepwell]

I'm not sure if this is a globus_sdk error or a pylint error, but pylint throws a "no-name-in-module" error with globus_sdk version 3.47.0 on python 3.12. Note, it is successful on python 3.13 or if globus version 3.46.0 is used.

Replicate this with a file file.py containing:

from globus_sdk import TransferClient

and by executing

pylint file.py

Could this be linked to #1100?

[sirosen]

It is! We actually run pylint internally as part of our CI for the SDK and disabled no-name-in-module because this is a false positive. I was vaguely wondering if #1100 would be noticeable to any users, and I guess that answers that!

There are two workarounds you can use right off the bat:

• if you use a type-checker (mypy, pyright), just turn off the rule as redundant
• try using --prefer-stubs yes -- I haven't tried this yet, but it's worth a shot

pylint is apparently pretty naive about --prefer-stubs, so I wouldn't be surprised if it causes other issues.

Sorry for the subtle change -- the new lazy importer is very much nicer for us, so unless there's a major issue I doubt we'd revert it.

[sirosen]

I just confirmed that prefer-stubs will work. In the SDK's own config, $ git diff -U1:

diff --git a/pyproject.toml b/pyproject.toml
index 63ec4a1d..2fffaf86 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -181,2 +181,3 @@ load-plugins = ["pylint.extensions.docparams"]
 accept-no-param-doc = "false"
+prefer-stubs = true

@@ -194,5 +195,2 @@ disable = [
     "protected-access",
-    # incorrect mis-reporting of lazily loaded attributes makes this lint
-    # unusable
-    "no-name-in-module",
     # objections to log messages doing eager (vs lazy) string formatting

We might switch to this ourselves, but I'm not sure yet. A lot of the member access lints in pylint are mostly or entirely redundant with type checking.

[ddeepwell]

Thanks @sirosen! Your suggested workarounds are sufficient for me.

[sirosen]

Fantastic! I'll close this as resolved, and we can use it as a reference if anyone else asks.

Of course, let us know if our import behavior is ever causing you significant difficulties -- we can try to address any problems!