[Async-sig] async/sync library reusage

[Yarko Tymciurak]

On Fri, Jun 9, 2017 at 12:48 AM Nathaniel Smith <njs at pobox.com> wrote:

> On Thu, Jun 8, 2017 at 3:32 PM, manuel miranda <manu.mirandad at gmail.com>
> wrote:
> > Hello everyone,
> >
> > After using asyncio for a while, I'm struggling to find information about
> > how to support both synchronous and asynchronous use cases for the same
> > library.
> >
> > I.e. imagine you have a package for http requests and you want to give
> the
> > user the choice to use a synchronous or an asynchronous interface. Right
> now
> > the approach the community is following is creating separate libraries
> one
> > for each version. This is far from ideal for several reasons, some I can
> > think of:
> >
> > - Code duplication, most of the functionality is the same in both
> libraries,
> > only difference is the sync/async behaviors
> > - Some new async libraries lack functionality compared to their sync
> > siblings. Others will introduce bugs that the sync version already solved
> > long ago, etc.
> > - Different interfaces for the user for the same exact functionality.
> >
> > In summary, in some cases it looks like reinventing the wheel. So now
> comes
> > the question, is there any documentation, guide on what would be best
> > practice supporting this kind of duality?
>
> I would say that this is something that we as a community are still
> figuring out. I really like the Sans-IO approach, and it's a really
> valuable piece of the solution, but it doesn't solve the whole problem
> by itself - you still need to actually do I/O, and this means things
> like error handling and timeouts that aren't obviously a natural fit
> to the Sans-IO approach, and this means you may still have some tricky
> code that can end up duplicated. (Or maybe the Sans-IO approach can be
> extended to handle these things too?) There are active discussions
> happening in projects like urllib3 [1] and packaging [2] about what
> the best strategy to take is. And the options vary a lot depending on
> whether you need to support python 2 etc.
>
> If you figure out a good approach I think everyone would be interested
> to hear it :-)
>

Just to leave this breadcrumb here - I've said this before, but not thought
in depth about it a lot, but pretty sure that in something like Python4,
async needs to become "first class citizen," that is from the inside out,
right in the bowels of the repl loop.

If async is the default, and synchronous calls just a special case (e.g.
single-task async), then I'd expect two things (at least): developers would
have an easier time, make fewer mistakes in async programming (the language
would handle more), and libraries would be unified as async & sync would be
the same.

Maybe there's something that would make this not make sense, but I'd be
really surprised.  Larry's gil removal work intuitively seems an enabler
for this kind of (potential) work...

-y



> -n
>
> [1] https://github.com/shazow/urllib3/pull/1068#issuecomment-294422348
>
> [2] Here's the same API implemented three different ways:
> Using deferreds: https://github.com/pypa/packaging/pull/87
> "traditional" sans-IO: https://github.com/pypa/packaging/pull/88
> Using the "effect" library: https://github.com/dstufft/packaging/pull/1
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20170609/92d8db3e/attachment.html>