Hi everyone, I'm trying to reboot conversation on this issue since I would love for this to land in Python 3.8.  At the recommendation of Terry Jan Reedy, here is my summary of where I think that the discussion is currently.  If anything is misrepresented, incorrectly linked, or if I misspelled anyones name, I apologize.  Feel free to correct any mistakes that you notice.

New subclass of TestCase versus enhancing unittest.TestCase
-----------------------------------------------------------

This was one of the primary discussion points since the start of this BPO.  I believe that Petter S (msg313454), Yury Selivanov (msg313695), and Andrew Svetlov (msg313481) were +1 on having a new sub-class of unittest.TestCase whereas Zachary Ware (msg313696) and R. David Murray (msg313413) would prefer that unittest.TestCase be enhanced to support async methods directly.

This is (in my opinion) the most contentious of the issues.  It also is the one with the largest impact on the implementation.  I feel that it is still largely up in the air amongst the core developers.

Lifecycle of the loop
---------------------

Whether the loop should live for the entire execution of a TestCase or for the execution of an individual test method came up a few times.  Nathaniel Smith (msg313455) was concerned about callbacks leaking between tests.  Yury Selivanov and Zachary Ware agreed that having a single event loop per class was acceptable (msg313696 and msg313700).

Support for other loops
-----------------------

Supporting 3rd party loop implementations (e.g., Tornado, Twisted, curio/trio) was discussed briefly.  The conclusion that I drew from the discussion is that the built-in testing class was not required to offer direct support to non-asyncio compatible loops.  Most notably msg313481 from Andrew Svetlov influenced my implementation.

Where should support live?
--------------------------

This is only relevant if we are not enhancing unittest.TestCase.  Petter S favored that the separate test case implementation live in asyncio instead of unittest.  I don't believe that anyone else had a strong opinion on this issue.

Should we have explicit methods for async behavior?
---------------------------------------------------

Yury Selivanov was most outspoken on explicitly named "async" methods like "asyncSetup", "asyncAddCallback", and the like.  Particularly in msg313695 and msg313700.  Zachary Ware seemed to agree that the separation was necessary but the functionality could be implemented by calling the async methods from the existing setUp and setUpClass methods (msg313699).


Did I miss anything?