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/
