[Python-ideas] async objects

[Rene Nejsum]

Hi Yann/

> On 03 Oct 2016, at 17:46, Yann Kaiser <kaiser.yann at gmail.com> wrote:
> 
> The way I see it, the great thing about async/await as opposed to threading is that it is explicit about when execution will "take a break" from your function or resume into it. This is made clear and readable through the use of `await` keywords.

The way I read this argument, a parallel could be “the great thing about alloc/free is that it is explicit about when allocation will happen”, but I believe that the more control you can leave to the runtime the better.

> Your proposal unfortunately goes directly against this idea of explicitness. You won't know what function will need to be fed into an event loop or not. You won't know where your code is going to lose or gain control.

I believe that you should be able to code concurrent code, without being to explicit about it, but let the runtime handle low-level timing, as long as you know your code will execute in the intended order.

br
/Rene


> 
> On Sun, Oct 2, 2016, 14:26 Rene Nejsum <rene at stranden.com <mailto:rene at stranden.com>> wrote:
> Having followed Yury Selivanov yselivanov.ml <http://yselivanov.ml/> at gmail.com <http://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 <http://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 <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 <mailto:Python-ideas at python.org>
> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas>
> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
> -- 
> Yann Kaiser
> kaiser.yann at gmail.com <mailto:kaiser.yann at gmail.com>
> yann.kaiser at efrei.net <mailto:yann.kaiser at efrei.net>
> +33 6 51 64 01 89
> https://github.com/epsy <https://github.com/epsy>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161004/a57764c0/attachment.html>