"Justin T." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | > 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 -- http://mail.python.org/mailman/listinfo/python-list