Add misc types for mock and unittest.mock - #3923

Looks uncontroversial, CI failures apart.

• check_consistent will want you to copy your changes to some other files.
• the stubtest failure actually appears to be an issue with how mypy detects what is public in a stub; it seems that just the presence of a type annotation for __all__ is enough to throw it off. I'll attempt to fix this in mypy, but for now you can follow its suggestion of just removing the unittest.mock things it mentions from the stubtest whitelists.

We don't type __all__ in stubs. __all__ can be used the same way it's used in implementation files, though, i.e. to list exported members.

@hauntsaninja thanks for the advice! I added those changes and pushed up

@srittau for some more context, I'm trying to work around this error:

$ mypy example.py
example.py:2: error: Module has no attribute "__all__"
example.py:3: error: Module has no attribute "__all__"

Where example.py is:

import unittest.mock, mock
print(unittest.mock.__all__)
print(mock.__all__)

And mypy is configured as follows:

$ mypy --version
mypy 0.770

$ cat setup.cfg
[mypy]
check_untyped_defs = true
disallow_any_generics = true
disallow_incomplete_defs = true
disallow_untyped_defs = true
no_implicit_optional = true

Some info about my system (code here):

• sys.version: '3.6.5 (default, Apr 26 2019, 13:23:36) \n[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)]'
• os.name: 'posix'
• sys.platform: 'darwin'
• platform.system(): 'Darwin'
• platform.python_implementation(): 'CPython'
• sys.implementation.name: 'cpython'
• sysconfig.get_platform(): 'macosx-10.14-x86_64'

I've seen __all__ typed this way in a few places so I thought this change was the right way to resolve the error.

@mxr Sorry for the delay. I was wrong with my answer. We discussed __all__ behavior in srittau/peps#67 (which is not strictly about typeshed). The conclusion was that __all__ should be included if and only if the implementation has it, which is the case with unittest.mock. But it should actually list the exported items, like the implementation, not just type it.

Thank you for the changes. Regarding the build failures:

• The stubtest failures are unrelated to this PR, see Add msilib and _msi to stubtest whitelist #3939.
• pytest stumbles over the __all__ annotation. Cc @rchen152
• The flake8 error seems to a problem with flake8/pyflakes. I will work around that in flake8 updates and cleanups #3940 and file a bug.

Thanks for the review! Since enumerating the contents of __all__ seems unsupported would it be acceptable to type __all__ using the same technique as other files and then do a batch migration of all __all__'s in another PR?

If this is a quick fix in pytype I'd prefer the "correct" solution, otherwise we can fall back to using the annotation only.

I'll look into fixing our parser. In the meantime, would it work to write

__all__ = [
 ...
]

? (Remove the annotation and use a list instead of a tuple?) pytype should already support that because it's the same syntax we use for slots.

@rchen152 sure I'll do that. Thanks!

CI is still unhappy. The stubtest failures are unrelated and should go away if you rebase, but the flake8 errors look real.

Actually they're not; the names are all defined. #3940 should fix this, so PR should now pass completely.

Will rebase. Thanks again, everyone, for all the guidance and white glove service on this PR!