Explicitly pass the kernel around instead of treating it as global

[catern]

This would make the various wrapper and helper classes in curio portable between different "kernels".

For example, io.Socket:

https://github.com/dabeaz/curio/blob/master/curio/io.py#L90

io.Socket only traps into the kernel for _read_wait and _write_wait. If io.Socket's constructor took arguments for _read_wait and _write_wait, io.Socket would be totally portable between event loops. A small wrapper function would make io.Socket usable with an identical interface on curio, asyncio, trio, whatever. In fact, io.Socket could even be used in a blocking mode, if blocking _read_wait and _write_wait functions were supplied.

I'm writing my own event loop for various reasons, and I started off by copying io.Socket from curio and changing the _read_wait/_write_wait to my own functions. But if io.Socket had this interface for passing in _read_wait, I wouldn't need to copy, I could use the same code. (A stable interface wouldn't be necessary, curio could still arbitrarily change io.Socket.)

[dabeaz]

One of the reasons Curio was created was in response to async libraries having too many interlocking components and dependencies, including the event loop. As such, I'm not inclined to bring something like this back into Curio as a core feature.

That said, let me think about it. Making Curio interoperate with other libraries has never been a primary goal, but it doesn't necessarily have to be impossible either.