AsyncMock stubs for mypy in Python 3.7 about mock HOT 5 CLOSED

To be clear: I think shipping separate stubs is a really bad idea for any python package, and I was strongly against that part of the PEP. They will invariably get out of date and cause more problems than they solve.

from mock.

Hi! I think the right way to do this would be to just add the type annotations you need upstream (ie: as a CPython PR) and then they will flow down to the backport here.

If you create such a PR, feel free to link it from this issue.

from mock.

Thanks @cjw296. There are stubs specifically for this package here, but they had the same type checks as the stdlib version here. I have just had a PR merged to fix this.

from mock.

You're missing my point: there's no need for separate type stubs, please add typing information you need as a PR to the actual code upstream, so that no separate stubs are needed.

(Unless I'm missing something: my understanding is that type stubs were only intended to be a stop-gap until the source code could have type annotations added to it, if you know different, please explain it to me!)

Also, your link to https://github.com/python/typeshed/blob/master/stubs/mock/mock.pyi gives me a 404.

from mock.

Sorry, I fixed the link.

What I mean is the stubs already existed and needed a small fix to solve the problem. I was wondering why the type annotations aren't already added to cpython, as it is much better for developing against. I am interested in doing that, but it will require significantly more effort and probably be a more drawn out review process to make sure nothing is broken.

from mock.