This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients André Caron, asvetlov, brett.cannon, gvanrossum, martin.panter, ncoghlan, vstinner, yselivanov
Date 2016-02-12.21:12:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1455311521.61.0.346349844063.issue25887@psf.upfronthosting.co.za>
In-reply-to
Content
> I haven't looked at the patch, but the intent to make the 2nd 
> await raise a RuntimeError seems strange for several reasons:
> - it's inconsistent with the Future/Task interface;

Well, coroutines are much more lower level than Future/Tasks.


> - it's quite common to await a 2nd time to get the coroutine 
> result after calling asyncio.wait(...) using ALL_COMPLETED or 
> FIRST_EXCEPTION;

I believe you're not using the asyncio.task() function correctly.  
From the docs:

"""Wait for the Futures and coroutine objects given by the sequence 
futures to complete. Coroutines will be wrapped in Tasks. Returns 
two sets of Future: (done, pending)."""


> - as mentioned in the mailing list the await keyword in 
> C#/Hack/JS which inspired the await keyword (as per PEP492) 
> returns the result/exception multiple times.

Yes, this was discussed at length on the mailing list.  There are
many reasons as to why we don't want coroutines to be awaitable
many times.  One of them is that we don't want low-level coroutine
objects to hold references to return values.  Coroutines in Python
are exhaustible resources (like generators).
History
Date User Action Args
2016-02-12 21:12:01yselivanovsetrecipients: + yselivanov, gvanrossum, brett.cannon, ncoghlan, vstinner, asvetlov, martin.panter, André Caron
2016-02-12 21:12:01yselivanovsetmessageid: <1455311521.61.0.346349844063.issue25887@psf.upfronthosting.co.za>
2016-02-12 21:12:01yselivanovlinkissue25887 messages
2016-02-12 21:12:01yselivanovcreate