Thanks for the submission, this looks good.

[If you're still around, I know it's been a while since you opened the PR,] can you tell us a bit more about how you're using this? I haven't used asyncio before, and want a better understanding of how this will likely be used.

We're going to introduce this soon

Thanks for the submission, this looks good.

[If you're still around, I know it's been a while since you opened the PR,] can you tell us a bit more about how you're using this? I haven't used asyncio before, and want a better understanding of how this will likely be used.

Hi David, thanks for taking a look. I have several classes that define async functions. These functions are normally awaited on in the standard execution of the program, but sometimes it's useful to use the CLI via Fire to execute these functions individually. As a workaround, I've been creating sync_<func> methods that do the equivalent of asyncio.run_until_complete(<func>()), but figured it would be more elegant if Fire supported this natively

One thing I'm wondering is: is there ever a time that you'd want to operate on the result of <func>() directly (where is a coroutine) by accessing one of its members?

fyi iscoroutinefunction fails when passed an lru_cache decorated function.
AttributeError: 'functools._lru_cache_wrapper' object has no attribute '__code__'
We'll need to wrap iscoroutinefunction to catch errors, and make sure this doesn't slow down standard usage of Fire too much (shouldn't be an issue).

Also inspect.findsource fails on something in the testFireAsyncio testcase with an IndexError which may end up being Python bug (but we'll adapt Fire to handle it) since the documentation says findsource should only raise OSErrors. Will have to dig into it later.