On Tue, Apr 28, 2015 at 11:51 AM, Stefan Behnel <stefan...@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 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