Guido van Rossum

Thanks for the thorough investigation!

Yes, (1) is pretty much on the mark. Re (2), we intentionally don't say too much about "current context" because its definition is actually dependent on the implementation of the...

(1) For docs we still use Hg, just submit your patch to bugs.python.org (more instructions at https://docs.python.org/devguide/). (2) But the distinction is not up to the event loop -- the...

(2) I'd prefer stating what the default policy does and explaining that each policy has its own interpretation. (3) The exact conditions are too hard to explain; the simplified rule...

-1 on spawn(), we already have a family of os.spawn*() functions that create subprocesses. -1 on start(), it's too generic (and doesn't do the same kind of thing as Thread.start()...

> The current name `asyncio.ensure_future` feels like that it "ensures" the full execution of the given Task or Future even when they have exceptions, but this is not true. Oh,...

Here's a counter-question. Why are you using these functions? My guess is that you've got a coroutine that you want to run "in the background", i.e. without waiting for it....

OK, I'm not totally against spawn() then. I think we should have a PEP describing all the (major) improvements we want to make to asyncio in Python 3.7 rather than...

But that example should be written without explicitly creating tasks at all: ```python loop.run_until_complete(asyncio.gather(foo('Alice'), foo('Bob'), asyncio.sleep(5))) ``` I suspect that overusing explicit tasks is probably a symptom of classical "thread"...

Yes, that's right. When using `await` (or `yield from`) the difference between coroutines and `Future`s (and between the latter and `Task`s) can be ignored. It's only when calling `.cancel()` that...