Message321479
> I don't see why asyncio should prevent people to experiment their own custom executor. You can imagine a custom "green executor" which inherit from Executor but uses its own black magic like greenlet.
Because asyncio and its ecosystem is built around the fact that the default executor is a ThreadPoolExecutor.
asyncio users are free to:
1. Pass any kind of executor as a first argument to `loop.run_in_executor()` -- no restrictions there.
2. Pass a subclass of ThreadPoolExecutor to `loop.set_default_executor()` -- that's how people can experiment.
Mind that (2) also covers exotic use cases like using greenlets under the hood (although I don't think it's possible), as long as they subclass ThreadPoolExecutor.
My plan so far:
* in 3.8 add a DeprecationWarning if an executor other than ThreadPoolExecutor is set as a default one.
* during 3.8 see what kind of feedback we get.
* if all goes great, in 3.9 we'll only allow subclasses of ThreadPoolExecutor. |
|
Date |
User |
Action |
Args |
2018-07-11 15:14:35 | yselivanov | set | recipients:
+ yselivanov, gvanrossum, vstinner, asvetlov |
2018-07-11 15:14:35 | yselivanov | set | messageid: <1531322075.6.0.56676864532.issue34075@psf.upfronthosting.co.za> |
2018-07-11 15:14:35 | yselivanov | link | issue34075 messages |
2018-07-11 15:14:35 | yselivanov | create | |
|