The attached patch implements asyncio.Task in C.  Besides that, it also implements Argument Clinic for C Future.

Performance improvement on a simple echo server implementation using asyncio.streams:

Python Future & Task   |   C Future & Py Task   |   C Future & C Task
      23K req/s        |           26K          |          30K
                       |      ~10-15% boost     |         ~15%

Both Task and Future implemented in C, make asyncio programs up to 25-30% faster.

The patch is 100% backwards compatible.  I modified asyncio tests to cross test Tasks and Futures implementations, i.e. to run Task+Future, Task+CFuture, CTask+Future, CTask+CFuture tests.  No refleaks or other bugs.  All uvloop functional tests pass without any problem.

Ned, Guido, are you OK if I merge this in 3.6 before beta 3?  I'm confident that the patch is stable and even if something comes up we have time to fix it or even retract the patch.  The performance boost is very impressive, and I can also make uvloop simpler.

Also, with this patch uvloop becomes ~3-5% faster too.

Wow! Great Job!
Yury, would you like to merge this before 3.6b3?
I'll look this as soon as possible.

(nit fix) Some modules doesn't sort imports in lexicography.

> Yury, would you like to merge this before 3.6b3?

Yes!

> I'll look this as soon as possible.

Thanks a lot!

If it's OK with Guido, it's OK with me for 360b3. (That's Monday.)

Very impressive.
I've left a couple comments in rietveld though.

I don't want to be the decider here. I don't have time to review the
code. I trust you all to do the right thing.

I also trust Yury to do the right thing.

Guido, Ned, thanks!  Andrew already glanced through the code, let's see what Inada-san says.

I'm uploading an updated patch addressing Andrew's review.

Uploading a new patch: sorted imports; added a unittest that exceptions in loop.call_soon aren't breaking Task.__init__.

Why isfuture() is moved, and asyncio.coroutine uses
base_futures.isfuture() instead of futures.isfuture()?

> Why isfuture() is moved, and asyncio.coroutine uses
> base_futures.isfuture() instead of futures.isfuture()?

Import cycles: 

- `_asyncio` module is now being imported from `futures.py`
- and `_asyncio` is now imported from `tasks.py`; 
- and `tasks.py` imports `futures.py` to have `isfuture`.

Long story short, I don't see a way of keeping `isfuture` in `futures.py`.  The easiest option is to have it in a separate module.

> - and `tasks.py` imports `futures.py` to have `isfuture`.

And tasks.py also imports coroutines.py (which was importing futures.py), making the cycle even worse.  Anyways, I don't see a problem in moving a function or two that everybody uses into a separate module.

New changeset db5ae4f6df8a by Yury Selivanov in branch '3.6':
Issue #28544: Implement asyncio.Task in C.
https://hg.python.org/cpython/rev/db5ae4f6df8a

New changeset 8059289b55c1 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28544)
https://hg.python.org/cpython/rev/8059289b55c1

I've committed the patch with a few touchups:

* Applied code-review feedback.

* We now use AC for all methods, including Task._repr_info, Task._step, etc. See [1].

* I fixed the Task to be fully subclassable; users can override Task._step and Task._wakeup now.  There are tests for ensuring that subclassing works the same for both Python and C implementations. See [2] and [3].

* I made it possible to override Future._schedule_subclass, as it was in Python 3.5. See [4].

Andrew, Inada-san, thank you for reviewing the patch!  Please take a look at the patch updates referenced below.  Feel free to re-open the issue if you see anything suspicious.

[1] https://github.com/1st1/cpython/commit/99adc35c94d76d78b8e666381436016c3c74a5ab

[2] https://github.com/1st1/cpython/commit/e294491c4cc7c92bc94ff12b4796c8ab12c40435

[3] https://github.com/1st1/cpython/commit/4d1c50c8987af124ce0bcccaea6bde82a60b59ee

[4] https://github.com/1st1/cpython/commit/efec03cbb4f81e78defd989d72c9bdae1122f50d

New changeset fb7c439103b9 by Victor Stinner in branch '3.6':
Issue #28544: Fix _asynciomodule.c on Windows
https://hg.python.org/cpython/rev/fb7c439103b9

Since asyncio becomes popular, IMO it is worth to mention this optimization at:
https://docs.python.org/dev/whatsnew/3.6.html#optimizations

Can you please do it Yury?

> Can you please do it Yury?

Yes, Elvis and I will be the editors of What's New this year anyways ;)

Python 3.6 & default don't compile on Windows because of the change:

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/2795/steps/compile/logs/stdio

       "D:\buildarea\3.x.bolen-windows8\build\PCbuild\_asyncio.vcxproj" (Build target) (15) ->
       (Link target) -> 
         _asynciomodule.obj : error LNK2019: unresolved external symbol _PyDict_Pop referenced in function task_step [D:\buildarea\3.x.bolen-windows8\build\PCbuild\_asyncio.vcxproj]
         _asynciomodule.obj : error LNK2019: unresolved external symbol _PyGen_Send referenced in function task_step_impl [D:\buildarea\3.x.bolen-windows8\build\PCbuild\_asyncio.vcxproj]
         D:\buildarea\3.x.bolen-windows8\build\PCBuild\amd64\_asyncio_d.pyd : fatal error LNK1120: 2 unresolved externals [D:\buildarea\3.x.bolen-windows8\build\PCbuild\_asyncio.vcxproj]

New changeset 635f5854cb3e by Yury Selivanov in branch '3.6':
Issue #28544: Fix compilation of _asynciomodule.c on Windows
https://hg.python.org/cpython/rev/635f5854cb3e

New changeset 9d95510dc203 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28544)
https://hg.python.org/cpython/rev/9d95510dc203

> Python 3.6 & default don't compile on Windows because of the change:

Pushed a fix for that.

New changeset db7bcd92cf85 by Yury Selivanov in branch '3.6':
Issue #28544: Pass `PyObject*` to _PyDict_Pop, not `PyDictObject*`
https://hg.python.org/cpython/rev/db7bcd92cf85

New changeset 60b6e820abe5 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28544)
https://hg.python.org/cpython/rev/60b6e820abe5

Looks like that Windows buildbot is green now. Closing.

New changeset 950fbd75223b by Victor Stinner in branch '3.6':
Issue #28544: Fix inefficient call to _PyObject_CallMethodId()
https://hg.python.org/cpython/rev/950fbd75223b

Just an FYI, for testing code that has both pure Python and C versions you can follow the advice in https://www.python.org/dev/peps/pep-0399/#details . And if you want to really simplify things you start down the road of what test_importlib uses: https://github.com/python/cpython/blob/master/Lib/test/test_importlib/util.py#L81 .