[issue43112] SOABI on Linux does not distinguish between GNU libc and musl libc
Change by Dave Shawley : -- nosy: +dave-shawley ___ Python tracker <https://bugs.python.org/issue43112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Dave Shawley added the comment: PR 10296 is my implementation of a unittest.TestCase subclass solution to this issue. This comment explains the approach and rationale in detail. Let's discuss this and see if the implementation meets expectations or should be abandoned. I refactored unittest.TestCase to isolate the running of test methods into a new helper method named _runTest and add a new hook named _terminateTest. The _runTest method is used to customize test method execution in sub-classes. The _terminateTest method is called from within the finally block in unittest.TestCase.run. It is an empty method in unittest.TestCase. This was the only change to unittest.TestCase. A new class unittest.AsyncioTestCase was added that implements async-based testing. It is a direct sub-class of unittest.TestCase that: * uses a @property named loop to lazily create an event loop instance * destroys the event loop instance in _terminateTest * re-implements _runTest to call new asynchronous hook methods * adds asyncSetUp and asyncTearDown methods that simply call the synchronous methods * re-implements doCleanups to call co-routines asynchronously Rationale - I used asyncio.iscoroutinefunction to detect if test methods or callbacks are co-routines. You explicitly opt-in to async behavior using the async marker on things that you want to run on the loop. This will cause problems with using the patch decorator on test methods since they will no not be detected as co-routines. I took this approach primarily to simplify the code and enforce explicitness. Since the implementation is a new sub-class, it cannot break existing code and new code can place the patch inside of the test method instead of decorating the method. I believe that creating an destroying the loop with each test method execution is the safest approach for managing the lifecycle. I view having the loop exist at the class level is an unnecessary optimization. I also ensure that code under test that calls asyncio.get_event_loop or asyncio.get_running_loop will receive the loop by calling asyncio.set_event_loop with the new loop. This came up in PR review with Petter S. The management of the loop is isolated into a property which makes it possible to create custom sub-classes that instantiate 3rd party loops that are asyncio compatible. This is the only concession that my implementation makes to supporting other loop classes. If it is not clear, I believe that a new sub-class of unittest.TestCase is necessary for a clean implementation. It preserves unittest.TestCase so the risk of breaking existing code is minimized and the async functionality is isolated in a new class that is explicitly meant to test async code. This is also necessary if the implementation should exist in the asyncio module. -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Dave Shawley added the comment: 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? -- ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Dave Shawley added the comment: I added a different implementation for consideration (https://github.com/python/cpython/pull/10296). -- pull_requests: +9606 ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32971] Docs on unittest.TestCase.assertRaises() should clarify context manager details
Change by Dave Shawley : -- keywords: +patch pull_requests: +9605 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32972] unittest.TestCase coroutine support
Dave Shawley added the comment: Hi all, I took a slightly different direction for adding async/await support to the unittest library. I summarized the approach that I took in a message to python-ideas (https://mail.python.org/pipermail/python-ideas/2018-October/054331.html) and a branch is available for preview in my fork of cpython (https://github.com/dave-shawley/cpython/pull/1). My question is whether I should reboot this bpo with my PR or create a new one since the implementation is different than what was already discussed? -- nosy: +dave-shawley ___ Python tracker <https://bugs.python.org/issue32972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
