logo       

Re: Practical uses of stackless technology: msg#00199

python.python-3000.devel

Subject: Re: Practical uses of stackless technology

Carl Friedrich Bolz wrote:
> Carl Friedrich Bolz wrote:
>> Hi stackless-dev!
>>
>> As some of you might know, the PyPy project is aiming at including many
>> of stackless' features into its Python interpreter. Most of them are now
>> implemented and we're now working on the report we are writing for the
>> EU about this part of our work.
>>
>> Being technical hacker types, we can cope with describing the ins and
>> outs of how our code works, but are less sure on the motivations for
>> stackless-style technologies as used in real-world applications :)
>> (especially since this part of PyPy is not used for any applications
>> yet).
>>
>> So this is where we come to you, the existing stackless community: why
>> are you interested in stackless? What benefits does it bring to you and
>> your business? (the EU always likes to hear that businesses are using
>> things :)
>>
>> As well as the more general stackless ideas (tasklets, channels, etc) we
>> are interested in hearing about any use people are making of the tasklet
>> pickling features.
>>
>> It would be wonderful if we could get some nice quotable, attributable
>> snippets, but general ideas would also be very welcome.
>>
>> Cheers and thanks,
>>
>> mwh & Carl Friedrich Bolz
>>
>
> argh! completely wrong list of course. Very sorry for the noise.

Maybe the wrong list - but maybe the right discussion. Specifically, how
much of the stackless technology should be adopted in Python3K?

I haven't used stackless myself, but I *have* written code that pushes
generators to their limits and beyond, and wanted something very much
*like* stackless's capabilities to be integrated into the mainstream.

My particular application is writing backtracking search engines,
Prolog-style unification, and so on. This requires writing generators
that communicate across many recursive stack levels.

One of these days I want to re-write my algebraic solver using a
stackless-type interpreter. Unfortunately I already have 3 versions of
Python installed on this machine (2.3 cause Mac OS X requires it, 2.4.4
because my primary apps haven't been ported to 2.5 yet, and 2.5 for
writing new code) and I really don't want to install yet another.

I understand, from reading the docs on stackless, that it jumps through
some fairly significant hoops to try and keep the Python C API intact.
Given the "cruft-removal" nature of Py3K, what could be done to minimize
the amount of hoop-jumping that stackless has to do?

-- Talin


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise