[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Bas Nijholt added the comment: I think this issue is related to the problem in https://bugs.python.org/issue36281 If it indeed is the case, then the fix proposed here and implemented in https://github.com/python/cpython/commit/22d25085db2590932b3664ca32ab82c08f2eb2db won't really help. --

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

STINNER Victor added the comment: Elvis Pranskevichus: well done, your first PR was already good to be merged ;-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

STINNER Victor added the comment: New changeset 22d25085db2590932b3664ca32ab82c08f2eb2db by Victor Stinner (Elvis Pranskevichus) in branch 'master': bpo-34075: Deprecate non-ThreadPoolExecutor in loop.set_default_executor() (GH-8533) https://github.com/python/cpython/commit/22d25085db2590932

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Change by Elvis Pranskevichus : -- keywords: +patch pull_requests: +8050 stage: -> patch review ___ Python tracker ___ ___ Python-b

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Andrew Svetlov added the comment: Agree, restricting to ThreadPoolExecutor sounds reasonable. A custom executor may have the same problem as ProcessPoolExecutor. Moreover it can work under same scenarios but crash with other third-party libs. -- _

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Yury Selivanov added the comment: > 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 t

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

STINNER Victor added the comment: > Other than subclasses of thread executor, what are you going to pass in? 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 mag

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Guido van Rossum added the comment: I disagree. Other than subclasses of thread executor, what are you going to pass in? A mock? On Wed, Jul 11, 2018 at 7:34 AM STINNER Victor wrote: > > STINNER Victor added the comment: > > > I think we'll only allow instances of c.f.ThreadPoolExecutor (an

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

STINNER Victor added the comment: > I think we'll only allow instances of c.f.ThreadPoolExecutor (and its > subclasses) to be passed to set_default_executor. That's a more robust check > than just guarding against ProcessPoolExecutor. I suggest to only reject ProcessPoolExecutor, instead of

[issue34075] asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor

Change by STINNER Victor : -- title: We should prohibit setting a ProcessPoolExecutor in with set_default_executor -> asyncio: We should prohibit setting a ProcessPoolExecutor in with set_default_executor ___ Python tracker