1

Suppose I have a package with an __init__.py like this:

# ifpy init script

import ifpy.world as world
import ifpy.grammar as grammar
import ifpy.util as util
import ifpy.cli as cli

__all__ = [*world.__all__, *grammar.__all__, *util.__all__, *cli.__all__]

from ifpy.world import *
from ifpy.grammar import *
from ifpy.util import *
from ifpy.cli import *

I'm making it specifically like this because it's supposed to be a public library and safe for import *. It works just fine when I use it in code, from ifpy import * and all the classes work without needing the ifpy.Class namespace (although you can also just do that as well) but mypy is telling me that those classes don't exist. Anyone else run into this problem? If you have, can you fix it and how?

EDIT: Note that if I from ifpy.world import * it works and mypy recognizes the import and type-checks accordingly.

Th31AndOnly
  • 45
  • 1
  • 6
  • _"safe for `import *`"_? Everything is _"safe for `import *`"_. The reason not to use it is because it is bad practice and it is definitely bad practice in your case. You have no idea what is imported and whether there is a clash between some `*` import and something else. I don't know what mypy does, but it would not surprise me if it intentionally ignores the `*` imports. – zvone Nov 20 '20 at 23:38
  • 1
    mypy is a type checker for python. This package I'm importing is my own and I know exactly what is being imported -- it works flawlessly. I'm saying mypy doesn't type-check beyond the import * – Th31AndOnly Nov 20 '20 at 23:52
  • 3
    @zvone: This is one of the few actual use cases of `import *`: combining the contents of multiple modules into one. It's pretty common in the standard library and all sorts of third-party packages, and it's much safer than importing `*` from code you don't control. – user2357112 Nov 20 '20 at 23:58

0 Answers0