specifically wrt to f403. python has a decades-old approach for importing desired names from a module. define __all__ with names that should be publicly available. python also allows for importing * from a module, which brings in everything from module.__all__.

this is particularly useful when creating packages, as, in __init__.py, you can from module import *, and the module remains the authority of what names should be publicly available. without import *, you end up managing two separate lists of names. one in module.__all__, which many python developers don't even bother defining, and one in __init__.py. this is a tiny pain in the ass that grows as a project grows.

even the pep8 documentation discourages wildcard imports, stating that there is only one defensible reason for using them. i use the __all__ and from module import * pattern in every project that requires a package. defining __all__ in a module reduces redundancy and encapsulates authority of module exports to the module itself. the extra step introduced by checking __init__.py, then checking module.__all__ is minimal, and is rarely, if ever, necessary, especially if a developer is familiar with the project and pattern.

are wildcard imports really evil, or are they just misunderstood, and is shunning them a herd-mentality response to developers' propensities for human error?