Hi Yann/

> On 03 Oct 2016, at 17:46, Yann Kaiser <kaiser.y...@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 <r...@stranden.com 
> <mailto:r...@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@python.org <mailto:Python-ideas@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.y...@gmail.com <mailto:kaiser.y...@gmail.com>
> yann.kai...@efrei.net <mailto:yann.kai...@efrei.net>
> +33 6 51 64 01 89
> https://github.com/epsy <https://github.com/epsy>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to