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
>>
>> On the surface of things, the single level aspect LOOKS like a
>> problem, but in fact is actually really useful. The reason is because
>> it encourages a generator to be relatively simple and focused
>> encouraging reuse.
>>
>
> Ah, perhaps Python should similarly limit function call nesting to one
> level so as to keep things simple and encourage reuse.
Bit of a grumpy response? ... and a straw man argument ? Generators can be
used to build co-operative multitasking (eg WSGI is implicitly co-op
multitasking), whereas function calls are used to build sequential code. I
agree for sequential code generators being single level can be rather
limiting. However, the thread is about co-operative multitasking.
Decades of experience has shown that the best way to build concurrent
systems (MASCOT[1], Unix, MPI, Occam, Erlang, even VHDL & some mashups)
is to have small things loosely connected. Generators encourage making
little things which then encourages connecting them together. It seems,
to me, to help. (Which is all I said really)
[1] Only recently heard about MASCOT - best reference is here:
http://async.org.uk/Hugo.Simpson/
(MASCOT is over 30 years old... (fun thing of the week that I've been
pointed at for me :-) )
It's the same basic ethos that makes Unix pipelines useful, and is why
WSGI is useful. Simple transformational things which work best when they're
pipelined together. The fact that you can't trivially nest generators in a
way that feels nice[2] IMO naturally encourages making small things, which
end up being reusable.
[2] I don't personally feel for i in X(): yield i is particularly nice.
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 namespaces, etc)... I even asked a question [3] on
that point before choosing python to write Kamaelia in... The fact that
it's been a benefit rather than a problem rather surprised me.
[3]
http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/fcd2709952d23e34/8a0b9ba0e3beb108
That's rather different from the recursion limit (which is a limit on
function call depth) that really *has* been a pain at times. (Something
which tail recursion would really help with)
Incidentally, you may note that you helped me back then (which I'm thankful
for :-), so you can kinda view this as me reporting back "actually, it's
turned out to be helpful rather than a pain" :-) Took a while to figure
that out though ;)
Your mileage may vary :)
Incidentally, it was probably your response (message 7) in that thread
that was responsible for me deciding to see where things could go by
trying python :-)
Merry Christmas,
Michael. (hoping that's a suitably positive response :-)
--
http://yeoldeclue.com/blog
http://kamaelia.sourceforge.net/Developers/
--
http://mail.python.org/mailman/listinfo/python-list
