stacklessemu

I use mobile broadband, and reducing bandwidth usage saves me a lot of money.  So when I wanted to play with pypes after hearing that Yahoo Pipes was being shut down, I somehow ended up taking Peter Szabo's greenstackless.py module, improving it a little, and putting it on a package up on PyPI.

It provides a good coverage of the Stackless API.  It's already been used as a backend for Peter Szabo's syncless project, and with the improvements I've made (adding the stackless.run() method, and fixing a greenlet/tasklet circular reference bug), it's even more capable.  But the devil is in the details.

It doesn't support the pre-emptive tasklet interruption that Stackless does, and can't as that is implemented via modifications to the internal Python VM source code.  Which is one of the few modifications Stackless makes in it's capacity as a fork of Python.  It is possibly possible to support this, as I believe Jeff Senn way back noted he had written a similar module with pre-emptive support based on the tracing hooks (with the downside that debuggers are unusable).

It doesn't support the threading model of Stackless Python.  This is derived by having a scheduler per thread, and most tasklets belonging to that scheduler at some level have slices of the stack of that thread and are therefore symbiotically attached to it.  It should be very possible to support this, with additional work, but that's something to set aside for when it's needed.

It doesn't support the module level properties, that Stackless implements.  And it can't unless it relies on hacks suggested in places like StackOverflow where classes are injected into 'sys.modules' to act as modules.

Future work I'm tempted to do is working out whether I can add the tealet project, as an alternative backend to the greenlet backend it currently has.  Greenlets are of course the stack slicing of Stackless extracted into an extension module.  tealet is the "next generation" version of the stack slicing intended for Stackless Python.  They're not using it already because it was such a wide ranging low level change to the workings of Stackless, that adopting it introduces potential instability which is not desirable at this time.

Kristjan Valur implemented a greenlet emulation module for tealet (in the same repo), so it may be that using it might be as simple as running stacklessemu on tealet.greenlets on tealet.  It's a pity it wasn't uploaded to pypi so I can try it out, but I don't think that's in Kristjan's wheelhouse.

The licensing situation of Greenlet

In order to use Stackless Python and gain what it offers, a custom version of Python needs to be installed. You may know about Greenlet which offers part of what Stackless does, and which can be installed as an extension module for your normal Python installation.

The MIT licensing of Greenlet

When it was extracted from Stackless Python, it was checked into the Py or PyPy repository or something. Py and PyPy are licensed under the MIT license, but as an oversight the licensing of the Greenlet code was never clarified. From there, it was handed off and maintained by Bob Ippolito. And from there, it made its way to the bitbucket repo. Along the way it inherited the MIT license.

The actual licensing of Greenlet

Greenlet contains parts of Stackless Python, specifically the assembler code related to switching between coroutines. Stackless Python as a derivative of regular Python has always just gone with the license of Python itself, so these files are still licensed under the Python license. Ideally the easy solution would be to get Christian Tismer to relicense them under the MIT license, but its not that easy. Between the time Christian wrote the original set of these files, and the time when they were extracted for Greenlet, other people (including myself) contributed both additional files and patches. To really relicense the code, all of these people would need to give approval (as I understand it). Who are all these people? I don't know.

So despite the MIT license that comes with it, and the declaration that it is MIT licensed on the Pypi page and elsewhere, to my understanding the project is effectively licensed under two licenses. For the files which came from Stackless, the Python license applies. And for the files which came from Armin Rigo, the MIT license implicitly applies.

And?

There's a bug on it.

A double licensing mish-mash isn't desirable for the project, and the easiest step forward is relicensing to the Python license to work around that as broached in the bug. I was going to offer to do the work of tracking down all the contributors and sorting this out.. but due to circumstances beyond my control I no longer have the time.