Please submit high-quality stubs for importlib

[gvanrossum]

I guess both PY3 and PY2 versions are wanted.

This came up in #183.

[brettcannon]

QQ about the sys.version checking support; is it reasonable to expect type checkers to follow the checks within a class definition, i.e. place a version guard around methods that were added in later versions of Python?

[gvanrossum]

That doesn't present any additional problems; the existing support for PY2 and PY3 in mypy already works that way.

[tharvik]

Any news? Or can I try to rewrite a cleaner version than #183?

[brettcannon]

I'm still planning on writing the stubs in the next month or so (a bit swamped with Python 3.6 stuff ATM).

[brettcannon]

Question for @gvanrossum: what directory should I put the stubs in? Importlib was introduced in Python 3.1, but a lot of things have been added over the years. Should I just put it into 3/ ? And how zealous should I be with version checks (e.g. a new method added in Python 3.4)?

And a reminder to myself, I should check what attributes modules have by default and in what versions of Python they became defaults

[gvanrossum]

I would put it in 3/, and add sys.version_info checks around new methods. (Mypy currently ignores those, but eventually we will make it respect them, so you might as well put them in now.)

[brettcannon]

I'm going to fix this issue step-by-step to make sure I'm doing it correctly, so I'm starting w/ importlib.__init__ and I will build from there.

I also noticed that the types module has the wrong details for modules, so I will fix that as part of this issue as well (__package__, __loader__, and __spec__ as initially set to None as of Python 3.4; __doc__ and __name__ have always existed).

[brettcannon]

So I have a problem where mypy doesn't like the Liskov violation that was purposefully introduced into importlib.abc (it's all for minimal backwards-compatibility with the deprecated ABC). We have an ABC that defines the method:

@abc.abstractmethod
def find_module(self, fullname: str, path: Sequence[_Path] = None) -> Optional[Loader]: ...

One subclass overrides this method as:

def find_module(self, fullname: str, path: Optional[Sequence[_Path]]) -> Optional[Loader]: ...

Notice how path no longer has a default value.

The other subclass overrides the method as:

def find_module(self, fullname: str) -> Optional[Loader]: ...

Notice how path is no longer even accepted.

How do you want me to handle this to make mypy happy?

[tharvik]

Usually, I was doing in the sub classes

def find_module(self,  # type: ignore
                fullname: str) -> Optional[Loader]: ...

That indeed remove the warning by telling mypy to stop caring about it. That may not be the best way to handle it, but I don't see any other which works with the current state of mypy.

[brettcannon]

Does mypy differentiate between instance, class, and static methods? I.e. is it worth redefining every method on a subclass if they are made e.g. classmethod?

[gvanrossum]

Mypy correctly distinguishes between the three types of methods (most of the time). I'm not sure what you're really asking -- if you really care, can you show a small example?

[brettcannon]

I'm just trying to be lazy. :) Basically I have an ABC that defines some method def foo(self) -> None: ... and a subclass that makes it a classmethod. I was trying to avoid copying the method from the ABC and adding the proper @classmethod and changing self to cls as I have a bunch of methods like that in importlib.machinery.