types.ModuleType should define __getattr__ that returns Any

[ilevkivskyi]

This will avoid false positives in several cases.

[JelleZijlstra]

I am trying this in master...JelleZijlstra:modulegetattr, but this produces some errors in mypy's test suite: https://travis-ci.org/JelleZijlstra/typeshed/jobs/391103559.

It seems that this change makes mypy thinks that any module has any attribute, while what we want is that specific module have a known set of attributes and only variables that are just typed as ModuleType have any attribute. This will likely require changes to mypy itself.

[ilevkivskyi]

Hm, yes, it looks like we have three tests that explicitly check for Module has no attribute "y". So probably this will need some adjustments in mypy (like not using __getattr__ when types.ModuleType is itself a fallback).

[gvanrossum]

I'd be very careful with changing this. In what situations is this needed?

[ilevkivskyi]

TBH, I already forgot why I wanted this :-) Most likely this is because of some limitations of type inference in mypy, when a list of modules is inferred with too wide type, or when people want to patch modules in a function.

However, if we will allow modules as subtypes of protocols (I promised to make a PR and it is still on my TODO list) this will solve all such problems, so maybe we can just abandon this idea? (I vote for protocols.)

[gvanrossum]

A typical example would be

import a, b, c  # It so happens that each defines a method foo()
mods = [a, b, c]
for mod in mods:
    mod.foo()

IIRC there was a tracker issue (maybe several) about this and I also believe I've seen it in Dropbox internal code.

[ilevkivskyi]

Yes, then the protocol solution (which doesn't work yet) would be to just give an explicit annotation to mods:

class Foo(Protocol):
    def foo(self) -> None: ...

import a, b, c  # It so happens that each defines a method foo()
mods: List[Foo] = [a, b, c]  # OK
for mod in mods:
    mod.foo()

[JelleZijlstra]

So it sounds like we shouldn't make any change in typeshed.