Relative/Absolute Wildcard Imports

[hmc-cs-mdrissi]

Why are relative and absolute imports treated differently for wildcard library error rule? I have a library I work on,

foo/
  a.py
  b.py
  __init__.py

and if I write in __init__.py

from .a import *
from .b import *

I get no errors. But if I write,

from foo.a import *
from foo.b import *

I get wildcard import errors. Style wise my codebase chose to always require absolute imports. I can ignore that rule, but don't really understand why relative imports should be allowed for defining public api of a library but not absolute imports.

I could also disable wildcard rule although I feel a bit meh there as I agree with the rule on don't import * other libraries (although file level disable helps here). But importing * for your own library for defining api feels safe to me and a lot less duplication then importing several dozen names.

This feels too minor for a bug report given the fallback option of just disable rule in few files that handle exporting public api. Also partly because I'm unsure if this relative vs absolute difference is intentional or a bug.

[erictraut]

As you point out, you can disable the reportWildcardImportFromLibrary diagnostic check if you don't like how it works. It's mainly designed for app/script developers who are new to Python and don't understand the significant downsides of using wildcards to import symbols from other libraries. It's not means for library authors, who are typically more knowledgeable.

Out of curiosity, why would you use absolute imports within a library to refer to its own submodules? This approach depends on proper installation of the library, which means these imports won't work development or in other situations where the library hasn't yet been installed in the active Python environment. It also makes your library vulnerable to unexpected module imports based on dynamic search paths in the user's environment. I've seen a few libraries use this approach, but I wouldn't recommend it. Relative imports are much better here, IMO.

[JelleZijlstra]

My experience in VSCode is that the pylance tool that autoadds imports uses absolute imports: it adds from my_package.my_module import name instead of from .my_module import name). I thought that was intentional, but your comment here makes me think it's a bug.

[erictraut]

@JelleZijlstra, Pylance's auto import feature never emits a wildcard import (absolute or otherwise). But I understand your point about it always emitting absolute imports rather than relative. The auto-import logic in Pylance optimizes for typical Pylance users who are not library authors. That said, there is a Pylance enhancement request to support relative auto-import suggestions. Please upvote it if you think it's a desirable enhancement. The Pylance team uses upvotes to prioritize their work.

[hmc-cs-mdrissi]

The installation issue, if they don't have it correctly installed I expect them to get a lot of errors from dependency packages. We have a small bash script that does needed pip commands to take care of installing packages my team works on. If a teammate/other internal user has an error with their environment I just tell them make a new venv and run bash script.

We also support development within a dev docker like environment that can handle environment issues for you. Although honestly we haven't convinced most people to use it. So far the bash script for handling setup mostly works.

As for why avoid relative imports, mostly this https://stackoverflow.com/questions/14132789/relative-imports-for-the-billionth-time. Relative imports start making you have to know difference between running a file as a script vs a module. I find absolute imports to be much simpler to understand. If you have things installed correctly then stuff will work. As we really want people to have correct installations so that our pre-commit checks happen, installation requirement is desired anyway. With relative imports, there's more knowledge needed of what they really do. I think that question being so highly up voted is a good example that for many python developers how relative imports work is confusing (most people don't know what python -m does). So my team just chose to ban them entirely for our code.