trio file io on asyncio

[buhman]

Would it be worthwhile to add subprojects under python-trio for various popular APIs
… gain the ability to run in "trio mode",

Not to suggest refactoring this all over again, but I've been thinking about #105 and #171. I think the _file_io stuff is actually pretty re-usable, even for asyncio (definitely much less scary than aiofiles anyway).

What do you think about ripping all of this back out, then making a python-trio/threaded-file-io or similar that supports creating both asyncio and trio threads (which I think is a fourth variant of #171 called *-libs-on-*, which we could also maybe apply to things like the stream API from #107).

[buhman]

I'm not sure if this makes it too complicated, but I was thinking the new library would provide something like:

def open_file_factory(thread_factory):
    …
    return open_file_that_uses_thread_factory

Then trio has a new extras dependency on the threaded-file-io library, and trio._file_io gets replaced with:

if threaded_file_io_available:
    __all__ += ['open_file']
    open_file = open_file_factory(thread_factory=trio.run_in_worker_thread)

Then it's just:

pip install trio[threaded_file_io]

[njsmith]

Whoops, I got confused about github's threading, and accidentally replied to this on the PR: #180 (comment)

[buhman]

but we failed to do so because we got distracted with other things and now no-one will ever know

Welp, I don't want to be that guy.

[njsmith]

Welp, I don't want to be that guy.

Sorry if I came over too intense there! If you want to make an asyncio library you should totally do that. I'm just trying to explain where my sometimes idiosyncratic opinions come from, personally :-)