Ken Manheimer a écrit : > On 7/10/07, *M. David Peterson* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > On 7/10/07, *Sylvain Hellegouarch* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Not to worry :) > However the question stands, will Python support closures (or > does it > already via lambda expressions?) > > > Depends on your interpretation of what a closure is. One > interpretation is that w ith closures you can, for example, have a > series of lambda expressions, evaluate up to a certain point, add > a marker, store it, and then continue where you left off at a > later date. > > > just to clarify, it sounds like you may be mistaking terminology here. > > the elementary structures by which computations can be stored for > later continuation are called just that - continuations. closures, on > the other hand, are an organization of program state that can be > associated with an object - typically to implement static scoping, as > was done for python functions and methods around, someone said, python > 2.1. i seem to recall that ruby manifests blocks as first class > objects, and associates closures with them, as well. > > (continuations are interesting, but mostly in the abstract - they're > not generally of interest for direct use by programmers. they're the > mother of all control flow structures - all the others can be > expressed and built using them, but they're very low-level - you would > hardly ever want to program with them directly. stackless python uses > (used?) them as a key means of building the other flow control > structures without using the machine (c, in that case) stack, and they > enable economies for massive parallelism that most of us don't need > (and couldn't handle without major attention). generators provide the > means to express much of what programmers practically want in this > vein, and the recent refinements to enable use of generators as > coroutines (pep 342 <http://www.python.org/dev/peps/pep-0342/>) covers > most of the rest. how these structures map to parallelism are up to > the language implementation. guido has been actively disinterested in > incorporating continuations to the python definition, for various > reasons, and i don't expect that to change.) > > i couldn't resist this clarification, and hope i haven't mistaken what > you were saying (or, what i'm saying:-). > > --
Thanks Ken as well for this explanation. This is one of those confusing subject for me and you helped a lot here :) Side note, talking about stackless, Arnar Birgisson just released yesterday a stackless version of the CherryPy HTTP server: http://code.google.com/p/stacklessexamples/wiki/StacklessWSGI Interesting days that is :) - Sylvain _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
