Integrating with Python 3.8

[Kentzo]

CPython accepted a commit that basically copies subset of asynctest into the standard library.

Should we champion our cause there?

Pros:

• No legacy: it's Python 3.8+ only
• We can alter mock's internals for our needs

[dimaqq]

@Kentzo would be nice state explicitly what "our cause" is :)

[Kentzo]

Full spectrum of features offered by asynctest of course :)

[Martiusweb]

Hi,

I discussed with Lisa Roach who contributed this to cPython. AsyncMock is actually borrowing code from CoroutineMock, which is great but makes it hard to make asynctest compatible with Python 3.8.

I'd be super happy to push more features from asynctest directly into cPython, in particular, an AsyncTestCase would probably be a nice addition.

I have yet to look in depth at what features have been introduced in unittest by AsyncMock and where it diverges from asynctest. Ideally, more and more features would be introduced in unittest, making asynctest progressively irrelevant and deprecated.

I've been slowly drafting a doc summarizing the changes I'd like to make to support Python 3.8:
https://docs.google.com/document/d/1w5QSXafNI7Xsswwbd56KFA6EEjCXgNMgmF_BwAgVsvE/edit

[Kentzo]

I have authored python/cpython#17133 yesterday which is essentially _AwaitedEvent for threads. If accepted it would allow to make another PR with _AwaitedEvent.

[dimaqq]

Re:

users should be able to replace all references of “unittest” with “asynctest”

I, for one, mix and match unittest.mock and asynctest. A whole bunch of unit tests run synchronously and those that require asynchrony specifically because code under test await’s something “external” use asynctest...

[dimaqq]

+1 on

deprecate asynctest.CoroutineMock

[dimaqq]

Re: AsyncTestCase
I’m squarely in the rosy pytest world, so no opinion here ;) Perhaps core devs may be Interested in better way to write tests like e.g. https://github.com/python/cpython/blob/master/Lib/test/test_asyncio/test_futures.py