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 gvanrossum
Recipients gvanrossum, python-dev, vstinner, vxgmichel, yselivanov
Date 2015-10-04.15:59:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I'm against that idea. I don't really see a great important future for this method either way: It's just a little bit of glue between the threaded and asyncio worlds, and people will learn how to use it by finding an example.

The existing ensure_future() function is mostly meant as an internal helper, with the understanding that libraries written on top of asyncio might also need this functionality. Basically I want people writing asyncio code not to have to worry about the difference between futures and coroutines, because they can both be awaited for; ensure_future() helps preserve that illusion for code that really needs a future (usually to add a callback).

But honestly I *don't* want to encourage flipping back and forth between threads and event loops; I see it as a necessary evil. The name we currently have is fine from the POV of someone coding in the threaded world who wants to hand off something to the asyncio world.

Why would someone in the threaded world have an asyncio.future that they need to wait for? That sounds like they're mixing up the two worlds -- or they should be writing asyncio code instead of threaded code.

OTOH, I would love to see the documentation update!
Date User Action Args
2015-10-04 15:59:31gvanrossumsetrecipients: + gvanrossum, vstinner, python-dev, yselivanov, vxgmichel
2015-10-04 15:59:30gvanrossumsetmessageid: <>
2015-10-04 15:59:30gvanrossumlinkissue25304 messages
2015-10-04 15:59:30gvanrossumcreate