Yury Selivanov <yseliva...@gmail.com> added the comment: > - I would say event loop per class. If someone really needs event loop per > method, they can create separate classes per method. It's ugly, but > effective.
+1. - We should have an async setUp capability. Maybe we could add a helper method to be called from setUp rather than adding a whole new asyncSetUp into the protocol? That eliminates the problem of which goes first. I'd rather have a protocol :) Protocols are easy to document and it's possible to statically validate them (with linters/metaclasses). Calling some method from setUp to call asyncSetUp would be a common gotcha IMO. We can always call synchronous setUp before asyncSetUp, I think it's intuitive enough. Speaking of addCallback, we should have a distinct addAsyncCallback. It's OK to have an object with both __call__ and __await__ methods -- in which case it's not clear which one you should call. In general, while we will be adding a new subclass and a few 'async'-prefixed methods, it should still be relatively straightforward for people to write and, more importantly, read the code that uses them. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32972> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
