Fake threads (was [Python-Dev] ActiveState & fork & Perl)

[Tim Peters]

[David Ascher]
> FWIW, I've been following the coroutine/continuation/generator bit with
> 'academic' interest -- the CS part of my brain likes to read about them.
> Prompted by Tim's latest mention of Demo/threads/Generator.py, I looked at
> it (again?) and *immediately* grokked it and realized how it'd fit into a
> tool I'm writing.  Nothing to do with concurrency, I/O, etc -- just
> compartmentalization of stateful iterative processes (details too baroque
> to go over).

"stateful iterative process" is a helpful characterization of where these
guys can be useful!  State captured in variables is the obvious one, but
simply "where you are" in a mass of nested loops and conditionals is also
"state" -- and a kind of state especially clumsy to encode as data state
instead (ever rewrite a hairy recursive routine to use iteration with an
explicit stack?  it's a transformation that can be mechanized, but the
result is usually ugly & often hard to understand).

Once it sinks in that it's *possible* to implement a stateful iterative
process in this other way, I think you'll find examples popping up all over
the place.

> More relevantly, that tool would be useful on thread-less
> Python's (well, when it reaches usefulness on threaded Pythons =).

As Guido pointed out, the API provided by Generator.py is less restrictive
than any that can be built with the "one frame" flavor of generator
("resumable function").  Were you able to make enough sense of the long
discussion that ensued to guess whether the particular use you had in mind
required Generator.py's full power?  If you couldn't tell, post the baroque
details & I'll tell you <wink>.

not-putting-too-fine-a-point-on-possible-vs-natural-ly y'rs  - tim