On Tue, Apr 28, 2015 at 11:51 AM, Stefan Behnel <stef...@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)
_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com