On Tue, Feb 24, 2015 at 10:56:49PM +1000, Anthony Towns wrote:
> On 24 February 2015 at 21:00, Steven D'Aprano <steve@pearwood.info> wrote:
>
> > If I have a function which expects a *primed* coroutine, and you provide
> > an unprimed one, we get an obvious error:
[...]
> ​Why would you ever want to use that function "unprimed", though?

I wouldn't. If I wrote a function that expected a coroutine as argument,
I would always expect that the caller would prime the coroutine before
sending it to me. If they forget, they will get an exception. But
Luciano seems to wish to accept both primed and unprimed coroutines, so
I'm just following his requirements as I understand them.

[...]
> ​But... you could just use a decorator to make that go away, I think? As in
> having a decorator along the lines of:
>
>   def primed_coroutine(f):
>       @wraps(f)
>       def fprime(*args, **kwargs):
>           co = f(*args, **kwargs)
>           next(co)
>           return co
>       return fprime

Indeed. That is exactly what I do in my code, so all my coroutines are
primed as soon as they are created and I never have to worry about
them being unprimed. My code is virtually the same as yours, except I
call the decorator "coroutine".

@coroutine
def running_sum():
    ...


makes it clear that running_sum is a coroutine, not a regular function
or generator.

Although the decorator is quite simple, I think that *every* user of
coroutines should be using it. Are there any use-cases for unprimed
coroutines? Perhaps this decorator should become a built-in, or at least
in functools?



--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/