Stackless Integration

[Terry Reedy]

"Justin T." <jmtulloss at gmail.com> wrote in message 
news:1186678307.205621.221100 at x40g2000prg.googlegroups.com...
| > And as far as I know or
| > could find in the PEP index, C. Tismer has never submitted a PEP asking
| > that it be made so.  Doing so would mean a loss of control, so there is 
a
| > downside as well as the obvious upside of distribution.
| That's true. Though, hopefully, the powers that be would allow him to
| maintain it while it's in the stdlib.

A commitment to maintain is a requirement, not something allowed.  By loss 
of control, I meant things like comforming to PSF's C and Python code style 
guide, responding to possible api change requests, and meeting doc and test 
suite requirement.  There is also the policy of no-feature-additions with 
bug-fix releases (x.y.*).  Is the development of stackless essentially 
finished?  and the design 'frozen'?

| Maybe we should file a PEP for| him... :)

You could offer to help him, but only he can offer his code.  Judging from 
discussions of other proposed additions, I expect that the PEP submitter(s) 
would have to substantively deal with questions like
* Do the C stack manipulations interfere with other operations, either core 
or extensions?  What test have you run to show that it does not.?
* Is the functionality portable to Jython and IronPython? (No is a strike 
against acceptance.)  If so, how easily?
* Generators were, in a sense, an alternative to continuation-stackless. 
The 2.5 addition of generator.send(), making communication more easily 
2-way, makes generators more like tasklets.  So why do we really need them? 
How about an alternative implementation built on generators?

If you want some idea of the type of back and forth discussion that may be 
involved, look at the discussion of Eby's generic functions PEP (3124) on 
the Py-3000 list.

Terry Jan Reedy