There is no need to create extra future and use loop.call_later to cancel base future from asyncio.wait_for when timeout==0. If loop is heavy loaded it can be cancelled simnifically later then 0 seconds later.

Do you have a use case where this optimization is important?

If coroutine function has some blocking calls before first await/yield from statement maybe makes sense do no let them be executed, if timeout equals 0

I think this is a backwards incompatible change and thus will be rejected.  Currently there's a guarantee that "wait_for" can throw a TimeoutError *only* when when you await it.

   fut = wait_for(something, 0)

   # some important code

   try:
       await fut
   except TimeoutError:
       # do something

With your PR merged, the above asyncio code would be broken, because asyncio users can guard with try..except only the await expression.

asyncio.wait_for is coroutine itself, to start executing code, no matter with this PR or not it needs to be awaited/yield from

import asyncio

@asyncio.coroutine
def foo():
    print(1)

loop = asyncio.get_event_loop()

fut = asyncio.wait_for(foo(), 0)

print('it is not raised yet')

try:
    loop.run_until_complete(fut)
except asyncio.TimeoutError:
    print('raised here')


will print 
it is not raised yet
raised here

You're right!  Let's work on the PR then, I've left a review comment.

Actually provided example without patch will print 1, which is not expected

Note, that this will not be backported to 3.6, as it behaves in a slightly incompatible way.  I consider this patch as an enhancement that makes 'asyncio.wait_for' semantics easier to reason about and more practical.