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 Decorater
Recipients Decorater, gvanrossum, vstinner, yselivanov
Date 2016-08-15.23:42:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1471304561.4.0.720328212485.issue27770@psf.upfronthosting.co.za>
In-reply-to
Content
I use a library that uses run_until_complete that is used for HTTP connections. However it does not work well when you want to reconnect anything that makes it start via recursion. So, I am suggesting the removal of run_until_complete and then tell everyone that uses it to replace their code that had it with run_forever.
( and to have their start function to create a event loop so that way if the loop is closed recursing to restart it after closed would make it not throw a RuntimeError)

run_forever seems to be almost exactly alike run_until_complete except it can run forever.

Pros with removing run_until_complete:
+ A lot easier to handle.
+ No pain from run_until_complete.
+ Cleanup some *code* in asyncio.
+ Helps with heavy http load for reconnecting websockets if they use run_forever instead.

Cons:
- Existing code from libs or anyone that uses run_until_complete will break.
- run_forever can still throw a RuntimeError if you try to use run_forever after closing a event loop.
- Event Loop would have to be recreated or reopened after being closed.
History
Date User Action Args
2016-08-15 23:42:41Decoratersetrecipients: + Decorater, gvanrossum, vstinner, yselivanov
2016-08-15 23:42:41Decoratersetmessageid: <1471304561.4.0.720328212485.issue27770@psf.upfronthosting.co.za>
2016-08-15 23:42:41Decoraterlinkissue27770 messages
2016-08-15 23:42:40Decoratercreate