types.ModuleType should define __getattr__ that returns Any #2147

Activity

1. JelleZijlstra

   added a commit that references this issue on Jun 12, 2018

   add __getattr__ to ModuleType

   ...

   This issue will close once commit ba2cabd is merged into the 'master' branch.

   ba2cabd
2. JelleZijlstra commented on Jun 12, 2018

   

   JelleZijlstra

   on Jun 12, 2018

   Last edited by JelleZijlstra

   Member

   More actions

   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.
3. ilevkivskyi commented on Jun 12, 2018

   

   ilevkivskyi

   on Jun 12, 2018

   MemberAuthor

   More actions

   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).
4. gvanrossum commented on Jun 12, 2018

   

   gvanrossum

   on Jun 12, 2018 via email

   Member

   More actions

   I'd be very careful with changing this. In what situations is this needed?
5. ilevkivskyi commented on Jun 12, 2018

   

   ilevkivskyi

   on Jun 12, 2018

   MemberAuthor

   More actions

   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.)
6. gvanrossum commented on Jun 12, 2018

   

   gvanrossum

   on Jun 12, 2018

   Member

   More actions

   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.
7. ilevkivskyi commented on Jun 13, 2018

   

   ilevkivskyi

   on Jun 13, 2018

   MemberAuthor

   More actions

   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()
8. JelleZijlstra commented on Jun 14, 2018

   

   JelleZijlstra

   on Jun 14, 2018

   Member

   More actions

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

   closed this as completedon Jun 14, 2018