Michael Sparks wrote:
> Also, I'd be interested in hearing how your project gets on - it
> sounds like the sort of thing that Kamaelia should be able to help
> with. (If it doesn't/can't, then it's a bug IMO :)
That was also my impression. :) My last tries had similarities to
Axon, but I never was
Duncan Booth wrote:
> There are also problems where full blown coroutines are appropriate. The
> example I quoted earlier of turning a parser from one which generates a
> lot of callbacks to one which 'yields' tokens is the usual example given.
For completeness, I looked at the other half of the
Bjoern Schliessmann wrote:
> Michael Sparks wrote:
>
>> All that said, my personal primary aim for kamaelia is to try and
>> make it into a general toolkit for making concurrency easy &
>> natural (as well as efficient) to work with. If full blown
>> coroutines turn out to be part of that c'est l
Hi!
Since your interest in fibers/coroutines is related to writing
simulators, you should try the SimPy package (simpy.sf.net), which is
a process-based discrete event simulator that uses generators as
processes.
On 22 dez, 09:10, Akihiro KAYAMA <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> I found co
Michael Sparks wrote:
> All that said, my personal primary aim for kamaelia is to try and
> make it into a general toolkit for making concurrency easy &
> natural (as well as efficient) to work with. If full blown
> coroutines turn out to be part of that c'est le vie :-)
I must admit I mostly did
Duncan Booth wrote:
[ snip sections about why the single layer aspect can be helpful ]
> I'm happy with generators as they are: they're a great solution to a
> problem that most of us didn't realise we had until the solution came
> along. That doesn't mean that I wouldn't also like to have a separ
Michael Sparks <[EMAIL PROTECTED]> wrote:
> To be clear - I REALLY didn't like the fact that generators were
> single layer when I first saw them - it seemed a huge limitation.
> (Indeed as huge a limitation as only having single level function
> calls, or only single layer of nesting for namespac
> Is there any plan of implementing real (lightweight) fiber in Python?
I have no such plan, and I don't know of anybody else's plan, either.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Duncan Booth wrote:
> Michael Sparks <[EMAIL PROTECTED]> wrote:
>
>> Duncan Booth wrote:
>>
>>> Unfortunately generators only save a single level of stack-frame, so
>>> they are not really a replacement for fibers/coroutines. The OP
>>> should perhaps look at Stackless Python or Greenlets. See
>
Michael Sparks <[EMAIL PROTECTED]> wrote:
> Duncan Booth wrote:
>
>> Unfortunately generators only save a single level of stack-frame, so
>> they are not really a replacement for fibers/coroutines. The OP
>> should perhaps look at Stackless Python or Greenlets. See
>
> On the surface of things,
Hi,
> It just works, but using native Python threads for non-preemptive
> threading is not cost-effective. Python has generator instead but it
> seemed to be very restricted for general scripting. I wish I could
> write nested (generator) functions easily at least.
>
> Is there any plan of imple
Duncan Booth wrote:
> Unfortunately generators only save a single level of stack-frame, so they
> are not really a replacement for fibers/coroutines. The OP should perhaps
> look at Stackless Python or Greenlets. See
On the surface of things, the single level aspect *LOOKS* like a problem,
but in
Akihiro KAYAMA <[EMAIL PROTECTED]> wrote:
> Thanks for your replies.
>
> But current Python generator specification requires me:
>
> def f1():
> for x in foo(f2, "foo"): yield x
> for x in foo(f2, "foo"): yield x
> # XXX v = ... (I don't know how to do this)
> for x in foo(f2, "v
Thanks for your replies.
In article <[EMAIL PROTECTED]>,
Arnaud Delobelle <[EMAIL PROTECTED]> writes:
arnodel> def f1():
arnodel> print "f1 start"
arnodel> yield f2,
arnodel> print "f1 foo"
arnodel> v = yield f2,
arnodel> print "f1 v=%s world" % v
arnodel> yield f2, "OK"
On Dec 22, 2:37 pm, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> > I am not really familiar with ruby but these fibers seem to be some
> > sort of coroutines. Since python 2.5, generators can be sent values,
> > this can be used to implement what you want
Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> I am not really familiar with ruby but these fibers seem to be some
> sort of coroutines. Since python 2.5, generators can be sent values,
> this can be used to implement what you want. I have had a got at it
> for fun and this is what I came up with
On Dec 22, 12:10 pm, Akihiro KAYAMA <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> I found cooperative multi-threading(only one thread runs at once,
> explicit thread switching) is useful for writing some simulators.
> With it, I'm able to be free from annoying mutual exclusion, and make
> results determ
Hi all.
I found cooperative multi-threading(only one thread runs at once,
explicit thread switching) is useful for writing some simulators.
With it, I'm able to be free from annoying mutual exclusion, and make
results deterministic.
For this purpose, and inspired by Ruby(1.9) fiber, I wrote my o
18 matches
Mail list logo
