FW: FW: [Python-Dev] Simple generator implementation

Christian Tismer tismer@tismer.com
Wed, 21 Mar 2001 13:52:05 +0100


Uche Ogbuji wrote:
> 
> > [Uche Ogbuji]
> > > Quite interesting.  I brought up this *exact* point at the
> > > Stackless BOF at IPC9.  I mentioned that the immediate reason
> > > I was interested in Stackless was to supercharge the efficiency
> > > of 4XSLT.  I think that a stackless 4XSLT could pretty much
> > > annihilate the other processors in the field for performance.
> >
> > Hmm.  I'm interested in clarifying the cost/performance boundaries of the
> > various approaches.  I don't understand XSLT (I don't even know what it is).
> > Do you grok the difference between full-blown Stackless and Icon-style
> > generators?
> 
> To a decent extent, based on reading your posts carefully.
> 
> > The correspondent I quoted believed the latter were on-target
> > for XSLT work, and given the way Python works today generators are easier to
> > implement than full-blown Stackless.  But while I can speak with some
> > confidence about the latter, I don't know whether they're sufficient for what
> > you have in mind.
> 
> Based on a discussion with Christian at IPC9, they are.  I should have been
> more clear about that.  My main need is to be able to change a bit of context
> and invoke a different execution path, without going through the full overhead
> of a function call.  XSLT, if written "naturally", tends to involve huge
> numbers of such tweak-context-and-branch operations.
> 
> > If this is some flavor of one-at-time tree-traversal algorithm, generators
> > should suffice.
> >
> > class TreeNode:
> >     # with self.value
> >     #      self.children, a list of TreeNode objects
> >     ...
> >     def generate_kids(self):  # pre-order traversal
> >         suspend self.value
> >         for kid in self.children:
> >             for itskids in kid.generate_kids():
> >                 suspend itskids
> >
> > for k in someTreeNodeObject.generate_kids():
> >     print k
> >
> > So the control-flow is thoroughly natural, but you can only suspend to your
> > immediate invoker (in recursive traversals, this "walks up the chain" of
> > generators for each result).  With explicitly resumable generator objects,
> > multiple trees (or even general graphs -- doesn't much matter) can be
> > traversed in lockstep (or any other interleaving that's desired).
> >
> > Now decide <wink>.
> 
> Suspending only to the invoker should do the trick because it is typically a
> single XSLT instruction that governs multiple tree-operations with varied
> context.
> 
> At IPC9, Guido put up a poll of likely use of stackless features, and it was a
> pretty clear arithmetic progression from those who wanted to use microthreads,
> to those who wanted co-routines, to those who wanted just generators.  The
> generator folks were probably 2/3 of the assembly.  Looks as if many have
> decided, and they seem to agree with you.

Here the exact facts of the poll:

     microthreads: 26
     co-routines:  35
     generators:   44

I think this reads a little different.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net/
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com/