Hello,

On Sun, 26 Apr 2015 16:13:43 -0700
Guido van Rossum <gu...@python.org> wrote:

> But new syntax is the whole point of the PEP. I want to be able to
> *syntactically* tell where the suspension points are in coroutines.
> Currently this means looking for yield [from]; PEP 492 just adds
> looking for await and async [for|with]. Making await() a function
> defeats the purpose because now aliasing can hide its presence, and
> we're back in the land of gevent or stackless (where *anything* can
> potentially suspend the current task). I don't want to live in that
> land.

And someone in this thread should have link in a signature to the page
on why there's not wanting to live in that land. I don't have it handy,
so may offer only reminiscence: if you don't know where there're
suspension points, you essentially should assume that any function call
can be a suspension point. And then you dropped almost as low as when
using threads - you can lose control anytime, data may change anytime,
you need to extensively use locks, etc.


Oh, and btw, there was related claim earlier that some things are better
done in thread pools, so async context managers can be done away with.
That's another faulty point - if asyncio is to be feature-complete, it
should work [well] with own functionality, without crutches of "foreign"
paradigms. Otherwise you may be just happy to use threads for
everything at all, like everyone did 5 years ago.

(And yeah, there's even usages for that, for example, MicroPython is
proudly GIL-free, translating to not supporting those thread thingies
and relying on native Python concurrency primitives).

> 
> On Sun, Apr 26, 2015 at 1:21 PM, Mark Shannon <m...@hotpy.org> wrote:
> 
> > Hi,
> >
> > I was looking at PEP 492 and it seems to me that no new syntax is
> > required.
> >
> > Looking at the code, it does four things; all of which, or a
> > functional equivalent, could be done with no new syntax.
> > 1. Make a normal function into a generator or coroutine. This can
> > be done with a decorator.
> > 2. Support a parallel set of special methods starting with 'a' or
> > 'async'. Why not just use the current set of special methods?
> > 3. "await". "await" is an operator that takes one argument and
> > produces a single result, without altering flow control and can
> > thus be replaced by an function.
> > 4. Asynchronous with statement. The PEP lists the equivalent as
> > "with (yield from xxx)" which doesn't seem so bad.
> >
> > Please don't add unnecessary new syntax.
> >
> > Cheers,
> > Mark.
> >
> > P.S. I'm not objecting to any of the other new features proposed,
> > just the new syntax.
> > _______________________________________________
> > 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/guido%40python.org
> >
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)



-- 
Best regards,
 Paul                          mailto:pmis...@gmail.com
_______________________________________________
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

Reply via email to