Message356898
I have submitted an alternative implementation of this feature heavily inspired by _AwaitEvent I wrote for asynctest [0].
There was recently an interest from the community towards asynctest to the point that got some of its measures merged into CPython [1].
The key features of my implementation [2]:
- Gives meaning to the existing Mock.called property, otherwise not much useful
- Does not require end users to do anything: change is automatically available in every Mock (and any subclass of mock that does not override `called`)
- Use of conditionals provides API that allows much richer extension: instead of hardcoding conditions as events it allows to wait until arbitrary predicate becomes true
- Utilizes existing semantics of python conditionals (both asyncio and threading)
Accepting this PR will allow me to bring _AwaitEvent thereby completing mock.py with waiting mechanics with identical semantics for both threading-based and asyncio-based cases.
0: https://github.com/Martiusweb/asynctest/blob/4b1284d6bab1ae90a6e8d88b882413ebbb7e5dce/asynctest/mock.py#L428
1: https://github.com/python/cpython/pull/9296
2: https://github.com/python/cpython/pull/17133 |
|
Date |
User |
Action |
Args |
2019-11-18 19:03:46 | Kentzo | set | recipients:
+ Kentzo, jcea, pitrou, rbcollins, cjw296, ezio.melotti, michael.foord, lisroach, mariocj89, lkollar, xtreak |
2019-11-18 19:03:46 | Kentzo | set | messageid: <1574103826.64.0.979162391957.issue17013@roundup.psfhosted.org> |
2019-11-18 19:03:46 | Kentzo | link | issue17013 messages |
2019-11-18 19:03:46 | Kentzo | create | |
|