Stackless Integration

[Justin T.]

Hi,

I've been looking at stackless python a little bit, and it's awesome.
My question is, why hasn't it been integrated into the upstream python
tree? Does it cause problems with the current C-extensions? It seems
like if something is fully compatible and better, then it would be
adopted. However, it hasn't been in what appears to be 7 years of
existence, so I assume there's a reason.

Justin

[Terry Reedy]

"Justin T." <jm*******@gmai l.comwrote in message
news:11******** **************@ i38g2000prf.goo glegroups.com.. .
| I've been looking at stackless python a little bit, and it's awesome.
| My question is, why hasn't it been integrated into the upstream python
| tree? Does it cause problems with the current C-extensions? It seems
| like if something is fully compatible and better, then it would be
| adopted. However, it hasn't been in what appears to be 7 years of
| existence, so I assume there's a reason.

First, which 'stackless'? The original continuation-stackless (of about 7
years ago)? Or the more current tasklet-stackless (which I think is much
younger than that)?

The original added a feature Guido did not want (continuations) and
required major changes to the core that would have make maintainance
probably more difficult for most of the developers, including GvR. For
more, see
http://www.python.org/dev/peps/pep-0219/

Second, what do you mean by integration? The current tasklet version is, I
am sure, as well integrated as Tismer can make it. Last I looked, there
were warnings about possible incompatibiliti es, but perhaps these have been
overcome. It is just not part of the stdlib. 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.

tjr

[Justin T.]

On Aug 9, 8:57 am, "Terry Reedy" <tjre...@udel.e duwrote:

First, which 'stackless'? The original continuation-stackless (of about 7
years ago)? Or the more current tasklet-stackless (which I think is much
younger than that)?

The current iteration. I can certianly understand Guido's distaste for
continuations.

>
overcome. It is just not part of the stdlib.

And I wish it were! It wouldn't be such a pain to get to my developers
then.

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. Maybe we should file a PEP for
him... :)

Justin

[Justin T.]

It's not Pythonic.

Jean-Paul

Ha! I wish there was a way to indicate sarcasm on the net. You almost
got people all riled up!

[Neil Cerutti]

On 2007-08-09, Justin T. <jm*******@gmai l.comwrote:

>

>It's not Pythonic.

Jean-Paul

Ha! I wish there was a way to indicate sarcasm on the net. You
almost got people all riled up!

Sorry. There's NO WAY to show sarcasm on the net. ;)

--
Neil Cerutti

[Aahz]

In article <sl************ ********@FIAD06 .norwich.edu>,
Neil Cerutti <ho*****@yahoo. comwrote:

>On 2007-08-09, Justin T. <jm*******@gmai l.comwrote:

>>JP Calderone:

>>>
It's not Pythonic.

Ha! I wish there was a way to indicate sarcasm on the net. You
almost got people all riled up!

Sorry. There's NO WAY to show sarcasm on the net. ;)

"If sarcasm were posted to the Net, would anybody notice?" --JDN
--
Aahz (aa**@pythoncra ft.com) <* http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier." --JMS

[Terry Reedy]

"Justin T." <jm*******@gmai l.comwrote in message
news:11******** **************@ x40g2000prg.goo glegroups.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