Open sethmlarson opened 4 years ago
Thanks for opening this issue!
I'm a bit surprised here because my understanding is that unasync exists specifically so that you don't need functions like await_or_return
. Instead return await x
in the async version of a package becomes return x
in the sync version.
But since you know that, what am I missing here?
I'm imaging a situation where your API takes a callable from the user and you'd like to support both Union[Callable[[...], X], Callable[[...], Awaitable[X]]]
on the async implementation but only support Callable[[...], X]
on the sync side. To do that you'd need a conditional await I think?
Maybe await_if_coro()
or something like this is a better name for this interface?
An example where this would be useful in Hip: When given a body that has read()
we want to call await f.read()
for async files and f.read()
on sync files.
Also anext()
would be useful in a similar place in Hip for generating the async iterators of bytes to send.
Right, this is needed when your API accepts both async and sync callables. Even though unasync is only a build dependency, I don't really mind adding utilities like that and making it useful as a runtime dependency too
Some utility functions I was thinking about:
Could also have
azip_longest
->zip_longest
, etc.All of the
async
functions could be available only on Python 3.6+ so this could be used on projects that support 3.5 or less.Could also provide type hints that are effected by
unasync
properly as well.This should probably be a separate project to unasync as unasync is primarily a build tool, raising it here because it'd make sense for the tool to live under
python-trio
, maybeunasync-utils
?