Author yselivanov
Recipients Petter S, asvetlov, njs, pdxjohnny, r.david.murray, yselivanov, zach.ware
Date 2018-03-12.20:52:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1520887966.11.0.467229070634.issue32972@psf.upfronthosting.co.za>
In-reply-to
Content
> - 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.
History
Date User Action Args
2018-03-12 20:52:46yselivanovsetrecipients: + yselivanov, r.david.murray, njs, asvetlov, zach.ware, pdxjohnny, Petter S
2018-03-12 20:52:46yselivanovsetmessageid: <1520887966.11.0.467229070634.issue32972@psf.upfronthosting.co.za>
2018-03-12 20:52:46yselivanovlinkissue32972 messages
2018-03-12 20:52:46yselivanovcreate