[IronPython] Hosting IronPython 2.X in .NET app
ken.manheimer at gmail.com
Tue Jul 10 16:08:50 PDT 2007
On 7/10/07, M. David Peterson <xmlhacker at gmail.com> wrote:
> On 7/10/07, Sylvain Hellegouarch <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
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:-).
As per our conversation in IM, this would certainly be one way to move
> towards a stackless and thread-free Python diet. ;-)
> Also, since we're on the subject, one *true test* of Python language
> interoperability would be to get Kamaelia ( http://kamaelia.org ) to work
> properly via IronPython.
> Kamaelia list (Cc'd): Has anyone attempted to get Kamaelia working with
> IronPython? If I am understanding things correctly, until support for
> generators are implemented then this would not be possible. Is this
> understanding correct?
> To the IronPython team: Having the ability to run Kamaelia (a brainchild
> of Michael Sparks of BBC Research) via IronPython would be an absolute dream
> come true. *AMAZING* potential existing bridging together Kamaelia and
> .NET, in my own opinion.
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
> users mailing list
> users at lists.ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users