[Python-ideas] async objects

[Giampaolo Rodola']

Independently from what the proposed solution is, I think you raised a very
valid concern: the DRY principle.
Right now the stdlib has tons of client network libraries which do not
support the new async model.
As such, library vendors will have to rewrite them by using the new syntax
and provide an "aftplib", "ahttplib" etc. and release them as third-party
libs hosted on PYPI. This trend is already happening as we speak:
https://github.com/python/asyncio/wiki/ThirdParty#clients
It would be awesome if somehow the Python stdlib itself would provide some
mechanism to make the existent "batteries" able to run asynchronously so
that, say, ftplib or httplib can be used with asyncio as the base IO loop
and at the same time maintain the same existent API.
Gevent tried to do the same thing with
http://www.gevent.org/gevent.monkey.html
As for *how* to do that, I'm sorry to say that I really have no idea. It's
a complicated issue, but I think it's good that this has been raised.


On Sun, Oct 2, 2016 at 3:26 PM, Rene Nejsum <rene at stranden.com> wrote:

> Having followed Yury Selivanov yselivanov.ml at gmail.com proposal to add
> async/await to Python  (PEP 492 Coroutines with async and await syntax and
> (PEP 525  Asynchronous Generators) and and especially the discussion about
> PEP 530: Asynchronous Comprehensions  I would like to add some concerns
> about the direction Python is taking on this.
>
> As Sven R. Kunze srkunze at mail.de mentions the is a risk of having to
> double a lot of methods/functions to have an Async implementation. Just
> look at the mess in .NET  when Microsoft introduced async/await in their
> library, a huge number of functions had to be implemented with a Async
> version of each member. Definitely not the DRY principle.
>
> While I think parallelism and concurrency are very important features in a
> language, I feel the direction Python is taking right now is getting to
> complicated, being difficult to understand and implement correct.
>
> I thought it might be worth to look at using async at a higher level.
> Instead of making methods, generators and lists async, why not make the
> object itself async? Meaning that the method call (message to object) is
> async
>
> Example:
>
> class SomeClass(object):
>    def some_method(self):
>        return 42
>
> o = async SomeClass()  # Indicating that the user want’s an async version
> of the object
> r = o.some_method()    # Will implicit be a async/await “wrapped” method
> no matter impl.
> # Here other code could execute, until the result (r) is referenced
> print r
>
> I think above code is easier to implement, use and understand, while it
> handles some of the use cases handled by defining a lot of methods as
> async/await.
>
> I have made a small implementation called PYWORKS (
> https://github.com/pylots/pyworks), somewhat based on the idea above.
> PYWORKS has been used in several real world implementation and seams to be
> fairly easy for developers to understand and use.
>
> br
> /Rene
>
> PS. This is my first post to python-ideas, please be gentle :-)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161003/6cbddc75/attachment.html>