Callable generators (PEP 288: Generator Attributes, again)

[Francis Avila]

Aahz wrote in message ...
>In article <55688f89.0311180211.7ab1bc30 at posting.google.com>,
>Francis Avila <francisgavila at yahoo.com> wrote:
>>
>>A little annoyed one day that I couldn't use the statefulness of
>>generators as "resumable functions", [...]
>
><raised eyebrow>  But generators *are* resumable functions; they just
>don't permit injection of new values into their state.

I see then that I don't need to convince you. :)  But it is because you
can't inject new values into their state that they are not resumable
functions.  They're pure state, not functions-with-persisting-state.  If
they were resumable functions, we could call them like functions and be
returned values based upon passed parameters, except that the algorithm used
would depend upon the generator's internal state.

Now, the above sounds like a class, doesn't it?  But yet we think of
generators as functions.  My post was an attempt to explain why this is so,
and argue for a set of semantics based on that perception (because the PEP
seems to want to regard them as classes).

Generators are funny because they share properties of classes and functions,
but I think they're more function-like than class-like, and that's why
class-like interfaces (i.e. generator attributes) are a strange fit.

>As Michele
>pointed out, it's easy enough to wrap a generator in a class if you want
>to monitor the changing state of an attribute.


True--you simply have to use 'self' to access public values, as the PEP
suggests.  The only advantage the PEP has is that we don't need to wrap
generators in a function to gain access to public attributes--the only
reason for the wrapper class anyway is to give a namespace between global
and local.  Anyone can do that, so why do we need a magic __self__
attribute?  So I agree, I don't like the PEP's specific proposal, but I
still like the functionality it's attempting to provide.

>The problem with injecting values is that there's no way to pick them
>up; it's a "push" solution rather than a "pull" solution.

You mean "pull" rather than "push"?

Well, I just suggested a way to pick them up which is no different than how
a function picks up parameters--they're pushed in rather than pulled in, by
overwriting the local namespace before advancing the generator's state.
Would you care to comment on my suggestion?
--
Francis Avila