Hi Guido, Hi List
I think it's too soon to start inventing new syntax to address these; instead, I strongly recommend changing your APIs to use explicit method calls instead of the special syntax you so favor. Even __getitem__() returning a Future feels awkward to me (unless it's clear that the container you have in front of you is a container full of Futures). [...] But again I would like to establish asyncio as the de-factor standard for asynchronous work before trying to tweak the language more
I agree that first we need to settle a bit and look how everything works, but hey, this is python-ideas, the list for "discussing speculative language ideas". Limiting all APIs to just use explicit method calls unfortunately leads to a very Java-like language that misses all the cool features of python. And this is not limited only to low-level stuff, but also high level interfaces. Right now I am actually working on a distributed framework, where users which are not professional programmers are supposed to write their own plugins. My boss is constantly bugging me "all that yield from stuff looks complicated, can't you just put it in a function the user calls so they don't see it anymore?" Well, as you know, I cannot. Even in the highest level of abstraction, every function that needs to do I/O has to be yielded from. Imagine the client side of a Big Data service like google earth, what syntax do you prefer, "yield from map.get_section(long1, long2, long_step, lat1, lat2, lat_step)", or simply "yield from map[long1:long2:long_step, lat1:lat2:lat_step]"? Until now, a yield from was just a rather rare case used only on special occasions. But once asyncio becomes more wide spread, it will simply be everywhere. It will be so ubiquitous that I even thought it should not be spelled out anymore at all - every expression evaluating to a coroutine should automatically be yielded from. But that would actually kill the advantange of this construct - the cooperative multitasking we are doing with yield from. The programmer of a piece of code would not know anymore where other tasks step in, so all the problems with race conditions re-appear. Given that it will be used very often in the future, I thought we could even use a special character to represent the yield from, say, a $. Then code like the following would be possible, please don't hate me for the Perl-look: for a, $b, c in some_iterator(): $ob.foo = $calculate(a + b, c) which would be equivalent to for a, _b, c in some_iterator(): b = yield from _b yield from ob.__setattr__("foo", yield from calculate(a + b, c)) But I guess with that I am just way too speculative... Greetings Martin