[Python-ideas] yield from __setitem__ and __setattr__

[Martin Teichmann]

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