Stubs for AsyncMock when using mock backport in Python <3.8

[GDYendell]

Is it possible to make the stubs for AsyncMock available for Python <3.8 when using the mock backport rather than unitest.mock?

Relates to testing-cabal/mock#500

[srittau]

I believe the reason the stubs for the mock backport have a version_info guard is that they started as a simple copy of the unittest.mock stubs. A PR to remove the version check (and update the version number in METADATA.toml would be welcome.

[GDYendell]

Ah OK, perfect. I will do that.

[srittau]

Fixed by #5948.

[cjw296]

Unless I'm missing something, why can't the type annotations just be added to the upstream mock.py and remove the need for separate typeshed stubs completely?

[srittau]

@cjw296 Inline type annotations or stubs shipped with upstream packages are preferred over separate type packages generated by typeshed.

[cjw296]

Right, so what's stopping that happening for Mock? @GDYendell: could you direct your energies to that instead of PRs to typeshed and opening issues on the mock backport?

[srittau]

Sorry, it seems I have misunderstood. By upstream, I was referring to the mock backports package, which could ship its own annotations, either by using a separate stubs file (possibly copying the one from here) or adding annotation inline. (Also, it would need to ship a py.typed package.) If the backports package just copies CPython's mock.py file, things will be harder as getting type annotations into CPython would probably need some convincing as they are not generally accepted.

[cjw296]

I'm one of the maintainers of mock in CPython, I also maintain the backport. I would welcome the addition of type annotations, and "not generally accepted" seems weird. @pablogsal, is that really the case?

I don't know what a py.typed package is, why would the mock backport need to ship with one?

[hauntsaninja]

py.typed is just a file that says "this package provides type annotations for static type checking"; it's the packaging convention that all type checkers follow as per PEP 561.

It has historically been the case that CPython doesn't accept type hints. It's worth noting that, imo, this has generally been good for users of static type checking: typeshed typically moves much faster than the CPython release cycle and improvements benefit users of all Python versions (type checking is a useful tool to help move between Python versions!).

I'll also note that mock is a tricky thing to static type (typeshed has made several changes / suffered several mock typing bugs, some regressions, in the last year) — probably not the module I'd pick to get annotations into CPython, if there's any chance of controversy.

[srittau]

I'm one of the maintainers of mock in CPython, I also maintain the backport. I would welcome the addition of type annotations, and "not generally accepted" seems weird.

That's great to hear and hopefully a first step to more type annotations directly in the stdlib. I'm not aware of any other CPython packages that use annotations. That said, type checkers will most likely not use stdlib annotations for now. This would most likely need another PEP to disentangle when a type checker can use stdlib annotations directly, when to use stubs shipped with CPython (not possible at the moment, but necessary for extension modules), and when to fall back to typeshed. Cf. #5444.

[cjw296]

Wow, what am absolute mess :-(