Python threading?

[Bengt Richter]

On Thu, 26 Sep 2002 11:39:04 -0400, Tim Peters <tim.one at comcast.net> wrote:

>[Robert Oschler]
>> Having written _many_ state machines in my life, which async programming
>> boils down to in one form or another, I feel it depends on the task.
>> ...
>> Contrast this with a simple procedure call where a linear series of
>> function calls are made, each with appropriate error handling and status
>> adjustment, in a pleasant centrally located manner.
>
>[Thomas Heller]
>> I wonder if generators can come to a rescue here?
>
>Absolutely.  Read the start of PEP 255.
>
>> Still trying to get them into my head...
>
>Think of them as resumable functions.  You're familiar with functions that
>remember their own data state across calls, via abusing globals, or via
>declaring private static vrbls, in C.  Methods on objects often do the same
>by stuffing their state into instance attributes between calls.  A generator
>remembers its data state across resumptions simply by virtue of that its
>local variables don't vanish, and also remembers its control-flow state
>across resumptions.  Remembering local data state by magic is a real
>convenience, but can be simulated in many other ways with reasonable effort;
>it's the ability to remember and restore control-flow state by magic that
>can make generators more than merely convenient.
>
Any thoughts on defining the next method with a generic *args optional arg list
and making it visible to an executing generator function g as g.__args__ ?

g.__args__ would then just be () for current usage, and could be
backwards-compatibly ignored as desired.

I'm thinking it would, e.g., provide a channel to pass messages etc to
a running task-implemented-as-generator.

Or you could pass control info to a tokenizer, e.g. telling it to back up
one and switch to profuse-info mode before yielding again, or whatever.

Another thought is to pass optional return args in the args tuple attribute
of the StopException object. This could be used variously, but might be used
to return a final result from a child task, where ordinary yields might be
reserved for control info for a dispatcher. Or it could be used to distinguish
exceptional return conditions without using other exceptions. Etc., etc.

This could also be reverse-compatibly ignored, but I think the two thoughts above
could open up a lot of possiblilities. Perhaps they have both been discussed before?

Regards,
Bengt Richter