[Python-Dev] PEP 492: No new syntax is required

Guido van Rossum guido at python.org
Tue Apr 28 22:00:26 CEST 2015


On Tue, Apr 28, 2015 at 11:51 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:

> Mark Shannon schrieb am 27.04.2015 um 09:48:
> > On 27/04/15 00:13, Guido van Rossum wrote:
> >> 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.
> >
> > I don't think I was clear enough. I said that "await" *is* a function,
> not
> > that is should be disguised as one. Reading the code, "GetAwaitableIter"
> > would be a better name for that element of the implementation. It is a
> > straightforward non-blocking function.
>
> 1) it's not like people commonly alias "repr()" or "len()", so why would
> they alias an "await()" builtin ? Unless, obviously, there's an actual
> reason to do so, in which case having it as a functions comes in handy. :)
> We had the same line of reasoning with "print()" back in the days of Py3k.
>
> 2) an "await()" builtin function that calls an "__await__()" special method
> on its input object sounds very pythonic.
>

This sounds confused. The await expression must be recognized by the parser
so it can generate different code for it (the code to suspend the stack). A
builtin function cannot generate different code -- to the compiler all
functions look the same. I know we could change that rule, but that' would
be a really a big deviation from Python's philosophy: Currently the code
generator never needs to know the type of any variables -- and a builtin
function 'await' would just be another variable to the code generator.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150428/3680df3e/attachment.html>


More information about the Python-Dev mailing list