On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov <yselivanov...@gmail.com> wrote:
> Hi Wolfgang, > > On 2015-04-23 8:27 AM, Wolfgang Langner wrote: > >> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky <pmis...@gmail.com> >> wrote: >> >> Hello, >>> >>> On Thu, 23 Apr 2015 12:18:51 +0300 >>> Andrew Svetlov <andrew.svet...@gmail.com> wrote: >>> >>> [] >>> >>> 3. >>>>> async with and async for >>>>> Bead idea, we clutter the language even more and it is one more >>>>> thing every newbie could do wrong. >>>>> for x in y: >>>>> result = await f() >>>>> is enough, every 'async' framework lived without it over years. >>>>> >>>> async for i in iterable: >>>> pass >>>> >>>> is not equal for >>>> >>>> for fut in iterable: >>>> i = yield from fut >>>> >>> But people who used Twisted all their life don't know that! They just >>> know that "async for" is not needed and bad. >>> >>> >>> I don't think it is bad nor not needed, but the syntax is not beautiful >> and >> for the 90% not doing async stuff irritating and one more thing to learn >> and do right/wrong. >> > There is no way to do things wrong in PEP 492. An object > either has __aiter__ or it will be rejected by async for. > An object either has __aenter__ or it will be rejected by > async with. > > transaction = yield from connection.transaction() > try: > ... > except: > yield from transaction.rollback() > else: > yield from transaction.commit() > > is certainly more irritating than > > async with connection.transcation(): > ... > > >> I had also a need for async loop. But there are other solutions like >> channels, >> not needing a new syntax. >> >> Also possible a function returning futures and yield in the loop with a >> sentinel. >> >> All this goes the road down to a producer consumer pattern. Nothing more. >> >> >> >> I know I'm a bad guy to make such comments, too bad there's a bit of >>> truth in them, or everyone would just call me an a%$&ole right away. >>> >>> >>> Generally, I already provided feedback (on asyncio list) that asyncio >>> is based not on native Python concepts like a coroutine, but on >>> foreign concurrency concepts like callback or Future, and a coroutine >>> is fitted as a second-class citizen on top of that. I understand why >>> that was done - to not leave out all those twisteds from a shiny new >>> world of asyncio, but sometimes one may wonder if having a clear cut >>> would've helped (compat could then have been added as a clearly separate >>> subpackage, implemented in terms of coroutines). Now people coming from >>> non-coroutine frameworks who were promised compatibility see "bad" >>> things in asyncio (and related areas), and people lured by a promise of >>> native Python framework see bad things too. >>> >>> >>> This has nothing to do with people using twisted or other async >> frameworks >> like tornado. >> I think a coroutine should be first class. But all this should be done in >> a >> way a beginner >> can handle and not design this stuff for experts only. >> > > I think that most of async frameworks out there are for > experts only. Precisely because of 'yield from', 'yield', > inlineCallbacks, '@coroutine', channels and other stuff. > > PEP 492 will make it all easier. And Twisted can use > its features too. > Yes and it is good to make it easier. But not complicate it for others. Beginners will be confronted with all this new syntax an my feel lost. Oh I have to different for loops, one with async. Same for with statement. > > If we do this we >> scare away new people. >> > > It doesn't scare away anyone. async/await were the most > awaited features in dart and javascript. One of the most > popular features in c#. > I like it in C#. I like await for Python but I don't like async there and how to specify it. I still think a decorator is enough and no special for and with syntax. async in JavaScript is for execution a whole script asynchronously used in the script tag. dart is for the google universe with less usage outside. -- bye by Wolfgang
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
