yield from __setitem__ and __setattr__
Hi list,
I am a happy user of yield from, especially while also using asyncio. A great feature is that one can seamlessly convert synchronous code into asynchronous code by adding the appropriate yield froms and coroutine statements at the proper place, including special methods like __getitem__, as in "yield from something[7]".
But we cannot yield from the special methods __setattr__ and __setitem__. That is unfortunate, as I am programming a proxy object for something remote over the network, and also __setitem__ might take some time. So I got the idea that yield from might also be used on the left side of an assigment, as in
yield from o[3], yield from o.something = "a", "b"
which should be equivalent to
yield from o.__setitem__(3, "a") yield from o.__setattr__("something", "b")
I know that with this proposal I am probably far up on the list of most ugly syntax proposed ever, so maybe someone has a better idea.
As a side note: with asyncio I am using yield from a lot, and I think it is a pity that it is so long an clumsy a keyword-couple. Couln't it be shortened? I'm thinking about just using "from", especially in an asyncio context, "from sleep(3)" sounds bad to me, but still better than "yield from sleep(3)". Or maybe we could have an auto-yielder, by just declaring that every expression that evaluates to a coroutine is automatically yielded from, as long as the calling function is a coroutine itself.
Greetings
Martin
There are a number of places where special syntax and yield-from don't mix well. (Another case is a generator to yield items to a consumer and the corresponding for-loop.)
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).
Regarding yield-from itself being somewhat awkward, I agree. (I like C#'s "await" keyword for this purpose.) But again I would like to establish asyncio as the de-factor standard for asynchronous work before trying to tweak the language more -- introducing a new keyword is a pretty heavy-handed change due to the way it invalidates all previous uses of the keyword. (Bare "from" cannot be used, since it would be confused with the "from ... import ..." statement.)
On Tue, Sep 9, 2014 at 10:36 AM, Martin Teichmann lkb.teichmann@gmail.com wrote:
Hi list,
I am a happy user of yield from, especially while also using asyncio. A great feature is that one can seamlessly convert synchronous code into asynchronous code by adding the appropriate yield froms and coroutine statements at the proper place, including special methods like __getitem__, as in "yield from something[7]".
But we cannot yield from the special methods __setattr__ and __setitem__. That is unfortunate, as I am programming a proxy object for something remote over the network, and also __setitem__ might take some time. So I got the idea that yield from might also be used on the left side of an assigment, as in
yield from o[3], yield from o.something = "a", "b"
which should be equivalent to
yield from o.__setitem__(3, "a") yield from o.__setattr__("something", "b")
I know that with this proposal I am probably far up on the list of most ugly syntax proposed ever, so maybe someone has a better idea.
As a side note: with asyncio I am using yield from a lot, and I think it is a pity that it is so long an clumsy a keyword-couple. Couln't it be shortened? I'm thinking about just using "from", especially in an asyncio context, "from sleep(3)" sounds bad to me, but still better than "yield from sleep(3)". Or maybe we could have an auto-yielder, by just declaring that every expression that evaluates to a coroutine is automatically yielded from, as long as the calling function is a coroutine itself.
Greetings
Martin
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (2)
-
Guido van Rossum -
Martin Teichmann