set_event_loop() cannot fail (it has a couple asserts but we can neglect this fact).

Sure it can. It calls policy.set_event_loop(), and given the fact that users can provide their own buggy policies, we can't really say that set_event_loop is 100% safe.

It's a flag of broken third party loop implementation, not user code problem.
Buggy loop can do weird things, I expect asyncio will be broken somehow anyway.

What's your point?

The point of this code is to always close the loop, no matter what. What benefit is there in moving set_event_loop() one line up?

Anyways, if you think that the code will read better if set_event_loop is outside of the try block I can move it. We call set_event_loop in the finally block along with the loop.close(), so as you say: if these things are broken then nothing will actually work anyways.

Well, it is very minor thing.
From my perspective wrapping loop.run_until_complete(main) only increases code readability a little but I can live with current implementation too.

I'll merge as-is then.

Never fails

Again, it can, if, say, I have a bug in uvloop.Loop.set_debug method. I prefer to assume nothing, when it's possible to set custom policies and custom event loops.

the loop argument should be removed now

Good catch!

this is a bit more concise

         while (loop.time() + 1.0) < end_time:
              print(datetime.datetime.now())
              await asyncio.sleep(1)

We can replace this while loop with for _ in range(5) and the example will only become clearer.

We'll have a separate pass over asyncio docs before 3.7 is released. We'll try to come up with better examples and improve the current ones. So for now, I'd keep this snippet as is.