<br><br>On Wednesday, June 27, 2012, Christian Tismer <<a href="mailto:tismer@stackless.com">tismer@stackless.com</a>> wrote:<br>> Hi Richard,<br>><br>> (why do you reply in private?)<br><br>Accident.<br>><br>
> On 26.06.12 21:59, Richard Tew wrote:<br>>><br>>> On Wed, Jun 27, 2012 at 1:16 AM, Christian Tismer <<a href="mailto:tismer@stackless.com">tismer@stackless.com</a>> wrote:<br>>>><br>>>> Stackless changes the python executable and is therefore not<br>
>>> absolutely easy to install.<br>>>> This is the reason why the greenlet is preferred so often over stackless.<br>>><br>>> I would say it was part of the reason.  The other part is that it<br>
>> tends to come as part of a library that enables easy use of<br>>> asynchronous IO, like gevent or eventlet.<br>><br>> Well, a recurrence. eventlet was probably developed on greenlet because of<br>> this difficulties.<br>
>><br>>> We should also concentrate on doing whatever needs doing on<br>>> stacklesslib and consider adding that as part of the Stackless<br>>> distribution.<br>><br>> If you can tell me more on this, that would be great.<br>
> I need to prepare my EuroPython talk where such things<br>> should be mentioned.<br><br>Kristján and I have discussed this in the past.  Like eventlet and gevent, it offers microthread friendly abstractions for IO.  And monkeypatching them in place so than existing threading-based code can transparently just work with the scheduler.<br>
<br>But there's the question, is it better to keep this a pypi hosted and installable package, or to provide it out of the box as part of the SLP distribution. Maybe it is not important.<br><br>>><br>>>> It suddenly struck me that the installation problem might simply<br>
>>> vanish or become invisible?<br>>>> With virtualenv or maybe some modification, it should be not so hard<br>>>> to make a stackless installation that creates a virtualenv configuration<br>>>> that does not impose headaches for newcomers.<br>
>>><br>>>> My dream-solution is<br>>>><br>>>>    pip install stackless<br>>><br>>> I think it is definitely a good idea, but it seems complicated.<br>>><br>>> We would be replacing the Python runtime, and injecting some standard<br>
>> library module changes.  If someone is using Python 3.2.1, I don't<br>>> think it is acceptable to silently give them the Stackless Python<br>>> 3.2.2 runtime.<br>>><br>> Yes, this needs a bit of thought.<br>
> Actually, we could require a compatible version and otherwise reject<br>> installation. To ask for the latest update of a python 2.x is probably<br>> ok. Alternatively, to support 2.x.y where y <> latest is possible, but<br>
> probably no good idea.<br>><br>> In any case, if people don't like what they get, they can pip uninstall,<br>> and be back where they were before. I think this makes a huge difference.<br>><br>> I think it makes sense to play even a bit more with the idea of<br>
> "treating" stackless like an extension without actually being one.<br>> It might even be possible without virtualenv if we can manage to find<br>> a good bootstrap trick. virtualenv was the vehicle to think about it.<br>
> Can be, can be not the best solution. Anyway better than all the humungous<br>> hackery that I thought  or two.<br>><br>> At least for python 3.3, I think something is possible using the builtin<br>> venv features, installing stackless bootstrapping in a user environment.<br>
><br>> If you get a concrete idea, please tell me ASAP, because I want to draw<br>> a road-map where stackless will probably go in the near future.<br>> My EuroPython talk is early next week, I'm preparing till Saturday.<br>
<br>Will do.<br><br>Cheers,<br>Richard.<br><br>>