<div dir="ltr"><div><div>FWIW, I am against this (as Alex already knows), for the same reasons I didn't like Nick's proposal. Fuzzing the difference between threads and asyncio tasks is IMO asking for problems -- people will stop understanding what they are doing and then be bitten when they least need it.<br><br></div>The example code should be written using loop.run_in_executor(). (This requires that do_something_cpu_heavy() be refactored into a function that does the work and a wrapper that creates the concurrent.futures.Future.)<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 7, 2015 at 6:51 PM, Alex Grönholm <span dir="ltr"><<a href="mailto:alex.gronholm@nextday.fi" target="_blank">alex.gronholm@nextday.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    There's an open issue for adding support for awaiting for
    concurrent.futures.Futures here:<br>
    <a href="http://bugs.python.org/issue24383" target="_blank">http://bugs.python.org/issue24383</a><br>
    <br>
    This is about writing code like this:<br>
    <br>
    <pre>async def handler(self):</pre>
    <pre>    result = await some_blocking_api.do_something_cpu_heavy()</pre>
    <pre>    await self.write(result)</pre>
    <br>
    As it stands, without this feature, some boilerplate is required:<br>
    <br>
    <pre>from asyncio import wrap_future</pre>
    <pre>async def handler(self):</pre>
    <pre>    result = await wrap_future(some_blocking_api.do_something_cpu_heavy())</pre>
    <pre>    await self.write(result)</pre>
    <br>
    I wrote a patch (with tests by Yury Selivanov) that adds __await__()
    to concurrent.futures.Future<br>
    and augments the asyncio Task class to handle concurrent Futures.<br>
    <br>
    My arguments on why we should add this:<br>
    <ul>
      <li>it eliminates the boilerplate code, reducing complexity<br>
      </li>
      <li>it also makes concurrent Futures work with "yield from" style
        non-native coroutines<br>
      </li>
      <li>it does not interfere with any existing functionality<br>
      </li>
      <li>standard library components should work with each other</li>
    </ul>
  </div>

<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>