Guido van Rossum added the comment:
Please move the philosophical discussion to python-ideas.
Regarding the phrasing about the two Future classes being almost compatible,
that is unfortunate wording. Two things can have a similar API (merely having
the same methods etc.) without being compatib
Sven R. Kunze added the comment:
> ... this sounds like it is encouraging staying ignorant.
True. However, I being ignorant about the complexity eventually led to the
development of high-level languages like Python. Each time, a next generation
simply asks the question: 'does it really need to
Guido van Rossum added the comment:
Yeah, we should strongly consider writing more documentation before adding more
convenience APIs. Esp. tutorial-style docs, which neither Victor nor I can
supply because we've already moved beyond wizard level ourselves so it's hard
for us to imagine the beg
Nick Coghlan added the comment:
I'll at least write a new python-ideas post, as I realised my original idea
*is* wrong (and you're right not to like it). The focus needs to be on Sven's
original question (How do you kick off a coroutine from otherwise synchronous
code, and then later wait for
Guido van Rossum added the comment:
> 1. You have to manage the lifecycle of the executor yourself, rather than
> letting asyncio do it for you
> 2. There's no easy process wide way to modify the size of the background task
> thread pool (or switch to using processes instead)
But if that's wha
Nick Coghlan added the comment:
The problems with using concurrent.futures directly for running synchronous
tasks in the background are:
1. You have to manage the lifecycle of the executor yourself, rather than
letting asyncio do it for you
2. There's no easy process wide way to modify the siz
