[IronPython] Hosting IronPython 2.X in .NET app

[Sylvain Hellegouarch]

Ken Manheimer a écrit :
> On 7/10/07, *M. David Peterson* <xmlhacker at gmail.com 
> <mailto:xmlhacker at gmail.com>> wrote:
>
>
>     On 7/10/07, *Sylvain Hellegouarch* < sh at defuze.org
>     <mailto:sh at defuze.org>> 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