Continuations and threads (was Re: Iterators & generators)

[Tim Peters]

[posted & mailed]

[Tim replies to Thomas Wouters, in a msg that get email'ed to Christian
 (because it griped about the lack of user-level Stackless docs), but
 apparently never made it to c.l.py due to the email outage at CNRI over
 the weekend of 26-Feb]

[Christian Tismer, now replies to that, as if anyone other than he & I
 saw it]

That was all by way of explaining why I'm not going to reply back on tech
points in detail.  Instead,

> ...
> Yessir. I felt guilty and added doc strings to everything I could find.
> This doesn't make things easier, but it is now much easier to find
> that out. :-)

Don't sell it short prematurely -- a single cryptic docstring is infinitely
more clue than users can get now.  For example, as you've seen here
recently, nobody but you has any idea what the purpose of .update() is.
This was just tough love <wink>.

> I was not sure about my continuation stuff, and I was waiting for
> some replies from the python-dev gurus. I thought they would read my
> paper with their given understanding of all the co-stuff, and given that
> everything should be obvious.

The implementation at that time, perhaps, but if you showed someone a
detailed implementation of, e.g., a cactus stack or an AVL tree, they would
still be left baffled by what the *point* to it all is. "If you're so smart,
how come you're not rich?" turns into "if this is so great, how come nobody
has done something mondo cool with it?".  I was always hoping Sam Rushing
would leap on this and fill that void with e.g. a Medusa on hyper steroids.
I'd do it myself, except for my well-known inablility to think up anything
useful <0.7 wink>.

> Now this dodn't work out. Quite a few dev-people did understand me,
> without giving me feedback beyond "great work, but what now?".

Indeed, AVL trees are almost unused in the real world despite their
theoretical attractions:  there's usually a simpler & faster way to get any
particular job done.  So generators won't sell this.  Coroutines, maybe, but
that too will need a specific app to make benefits obvious.

> Instead, I get lots of feedback from the "outer" world, and people
> seem to really want to try this stuff, even when they have no clue
> about anything that is non-procedureal.
> I have to change some policies :-)

Bingo.

> ...
> Next time I will publish a how-to: How to get mad with continuations,
> compared to other ways of becoming unhappy.

The best way to do that is to read Guido's essay on metaclass programming,
study everything he did carefully, and write something the exact opposite in
every respect except for accuracy -- am I joking?  Only partly.  Almost
everyone who had the slightest interest in metaclass programming ran
screaming in terror from that essay -- and, AFAIK, nobody has done anything
useful with the Python-level metaclass hook either.

> [info about the new implementation]

Never mention the implementation in public again <0.5 wink>.

> ...
> SLP 1.1 is much simpler and much more powerful. You can now
> run any frame at any time, even from a different thread.

Why is that good?  (It's a rhetorical question:  the response info like this
evokes is indeed "great work, but what now?")

> And the code has become shorter.

Frankly, nobody cares <0.1 wink -- pretend you're trying to sell a new brand
of deodorant -- nobody cares if it's 7.8% less dense than before, but will
be very impressed if you say it contains the new magic ingredient X3CT5 --
or especially if you imply that their chance of having sex again drops to
zero unless they buy it>.

> Not to mention that it is also faster than ever before:
> 7% more pystone than standard Python, although I have the
> safe destructors of nested structures in it. Ahem :-)

Now *that* lights up eyeballs across the globe!  People can put that on
their plates, stab it with a variety of dinner forks, chew on it until they
puke, and then beg for more.  So sell it as an internal optimization of no
further consequence <wink>.

> Unfortunately, this paper is now *INVALID*.
> I have to do a major rewrite.
> Readers, please forget about the chapter concerning frame
> compatibility. THIS IS NOT TRUE.
> Please, also forget about dispatcher objects. THEY ARE GONE.

Well, ya, OK, *I'm* interested <wink> -- but you don't have to sell it to
me, and I'm not positive anybody else (besides Jeremy) has actually read the
paper.  A concise but accurate implementation sketch is sufficient for
developers.  This needs something else to make progress.

like=a-catchy-slogan-or-celebrity-endorsement<wink>-ly y'rs  - tim