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

[Michael Foord]

JoeSox wrote:
> On 7/6/07, Chris Parnin <[EMAIL PROTECTED]> wrote:
>   
>> I've seen several examples of how to embed IronPython 1.X in .NET.
>> (e.g. IronTextBox) However, the architecture has changed greatly with
>> 2.X.  Does anyone have a good example or pointers on hosting an
>> interactive IronPython session in a .NET app?
>> 
>
> One of the reasons why I haven't updated IronTextBox is that
> IronPython 2 is in Alpha.  I decided to wait until it was Beta.  

I am eagerly awaiting both the next release of IronPython 2 and a 
version of IronTextBox that supports it. :-)

> On
> top of that, Python is set for a major version upgrade soon, so I
> don't know how this will effect IronPython's development.  I am
> wondering if others are thinking the same?
>   

If you mean Python 3... I wouldn't worry about it. Python 3 won't be in 
Beta until next year, and probably the middle of next year. It won't be 
the 'standard' version of Python for at least a couple of years and 
possibly more...

Michael Foord
http://www.voidspace.org.uk/ironpython/index.shtml
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Sylvain Hellegouarch]

Ken Manheimer a écrit :
> On 7/10/07, *M. David Peterson* <[EMAIL PROTECTED] 
> > wrote:
>
>
> On 7/10/07, *Sylvain Hellegouarch* < [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 ) 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

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

[Ken Manheimer]

On 7/10/07, M. David Peterson <[EMAIL PROTECTED]> wrote:



On 7/10/07, Sylvain Hellegouarch <[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)
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:-).

--
ken
http://myriadicity.net

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:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155

___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/10/07, Sylvain Hellegouarch <[EMAIL PROTECTED]> wrote:



I can understand your feeling but the core of the library is actually
pure Python and very small. It's only all its extra features that do use
C libraries. The core of Kamaelia is Python.



Didn't see your response before my last response.  Thanks for the
clarification!

I'm trying to use it with IP2A2 but I get a huge mono traceback

currently (mono from svn compiled IP2) so well... not getting really far
at the moment :)



I'll try it on Windows and see if the result is any different.

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Sylvain Hellegouarch]

Dino Viehland a écrit :
>
> Does Kamaelia use the new syntax as supported via PEP-342 
> (http://www.python.org/dev/peps/pep-0342/).  That’s the particular 
> piece that we don’t support and is new to 2.5 – we do support 
> generators when you use yield as a statement instead of as an 
> expression (in other words, we don’t support the send method on the 
> generator – only next).  It’s hard to tell as 1.5.1 was released 
> shortly after Python 2.5 and I don’t see any statements about which 
> version of Python is required.
>
>  
>
> Looking at all the various things it supports I would be shocked if 
> there wasn’t some use of the C-based extension API (which would 
> prevent, at least some portions, from working).
>
I can understand your feeling but the core of the library is actually 
pure Python and very small. It's only all its extra features that do use 
C libraries. The core of Kamaelia is Python.

I'm trying to use it with IP2A2 but I get a huge mono traceback 
currently (mono from svn compiled IP2) so well... not getting really far 
at the moment :)

- Sylvain

___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Dino Viehland]

Does Kamaelia use the new syntax as supported via PEP-342 
(http://www.python.org/dev/peps/pep-0342/).  That’s the particular piece that 
we don’t support and is new to 2.5 – we do support generators when you use 
yield as a statement instead of as an expression (in other words, we don’t 
support the send method on the generator – only next).  It’s hard to tell as 
1.5.1 was released shortly after Python 2.5 and I don’t see any statements 
about which version of Python is required.

Looking at all the various things it supports I would be shocked if there 
wasn’t some use of the C-based extension API (which would prevent, at least 
some portions, from working).

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. David Peterson
Sent: Tuesday, July 10, 2007 1:06 PM
To: Discussion of IronPython
Cc: [EMAIL PROTECTED]
Subject: Re: [IronPython] Hosting IronPython 2.X in .NET app


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.

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:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | 
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/10/07, Jacob Lee <[EMAIL PROTECTED]> wrote:



Closures have existed in Python since version 2.1 or so:
def f():
x = 5
return lambda: x
closure = f()
print closure() # prints 5

Here, the anonymous inner function returned by f is able to refer to
variables defined in outer scopes.



Oh, nice!  This is did not know.  So then are closures available now in IP?

As for the Python 3000 question --

The one current limitation is that you cannot rebind names defined in
outer scopes.



To me that's a feature, not a limitation. ;-)

That is, the following code does not work as expected:


def f():
x = 5
def g():
x = 7 # x is local to g here

You could use the "global" statement to indicate that x is a global
despite it being assigned to inside the function, but there was no
equivalent way to indicate that x refers to a variable in an outer, but
non-global, scope. Python 3000 will introduce the "nonlocal" statement that
works like the global statement to fill this gap. As usual, the best source
is the relevant PEP: http://www.python.org/dev/peps/pep-3104/

Hope this helps.



It does.  Thanks!

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/10/07, Sylvain Hellegouarch <[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 with 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.

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:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Sylvain Hellegouarch]

Jacob Lee a écrit :
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:users-
>> [EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch
>> Sent: Tuesday, July 10, 2007 12:54 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Hosting IronPython 2.X in .NET app
>>
>> Curt Hagenlocher a écrit :
>> 
>>> On 7/10/07, *Curt Hagenlocher* <[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>> On 7/10/07, *Dino Viehland* < [EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>> Major things we know we still have to do include yield
>>> expressions (sorry, there's probably a technical term for
>>>   
>> them)
>> 
>>> Closures :P.
>>>
>>>
>>> Doh! I'm so retarded that I misspelled "generators" :(.
>>>
>>> Apparently I've been reading too much about Ruby lately...
>>>   
>> Not to worry :)
>> However the question stands, will Python support closures (or does it
>> already via lambda expressions?)
>>
>> (/me is lame at language theory)
>>
>> - Sylvain
>> 
>
> Closures have existed in Python since version 2.1 or so:
> def f():
> x = 5
> return lambda: x
> closure = f()
> print closure() # prints 5
>
> Here, the anonymous inner function returned by f is able to refer to 
> variables defined in outer scopes.
>
> As for the Python 3000 question --
> The one current limitation is that you cannot rebind names defined in outer 
> scopes. That is, the following code does not work as expected:
>
> def f():
> x = 5
> def g():
> x = 7 # x is local to g here
>
> You could use the "global" statement to indicate that x is a global despite 
> it being assigned to inside the function, but there was no equivalent way to 
> indicate that x refers to a variable in an outer, but non-global, scope. 
> Python 3000 will introduce the "nonlocal" statement that works like the 
> global statement to fill this gap. As usual, the best source is the relevant 
> PEP: http://www.python.org/dev/peps/pep-3104/
>
> Hope this helps.
>   


Many thanks Jacob. I will admit that I don't often use lambdas in my own 
code and therefore when asked a straight question aboud them I dodged :)


That's what I thought of course


Thanks again.
- Sylvain
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Jacob Lee]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:users-
> [EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch
> Sent: Tuesday, July 10, 2007 12:54 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Hosting IronPython 2.X in .NET app
>
> Curt Hagenlocher a écrit :
> > On 7/10/07, *Curt Hagenlocher* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > On 7/10/07, *Dino Viehland* < [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Major things we know we still have to do include yield
> > expressions (sorry, there's probably a technical term for
> them)
> >
> > Closures :P.
> >
> >
> > Doh! I'm so retarded that I misspelled "generators" :(.
> >
> > Apparently I've been reading too much about Ruby lately...
>
>
> Not to worry :)
> However the question stands, will Python support closures (or does it
> already via lambda expressions?)
>
> (/me is lame at language theory)
>
> - Sylvain

Closures have existed in Python since version 2.1 or so:
def f():
x = 5
return lambda: x
closure = f()
print closure() # prints 5

Here, the anonymous inner function returned by f is able to refer to variables 
defined in outer scopes.

As for the Python 3000 question --
The one current limitation is that you cannot rebind names defined in outer 
scopes. That is, the following code does not work as expected:

def f():
x = 5
def g():
x = 7 # x is local to g here

You could use the "global" statement to indicate that x is a global despite it 
being assigned to inside the function, but there was no equivalent way to 
indicate that x refers to a variable in an outer, but non-global, scope. Python 
3000 will introduce the "nonlocal" statement that works like the global 
statement to fill this gap. As usual, the best source is the relevant PEP: 
http://www.python.org/dev/peps/pep-3104/

Hope this helps.

--
Jacob Lee
SDE Intern, Dynamic Language Runtime
<[EMAIL PROTECTED]>


___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Sylvain Hellegouarch]

Curt Hagenlocher a écrit :
> On 7/10/07, *Curt Hagenlocher* <[EMAIL PROTECTED] 
> > wrote:
>
> On 7/10/07, *Dino Viehland* < [EMAIL PROTECTED]
> > wrote:
>
> Major things we know we still have to do include yield
> expressions (sorry, there's probably a technical term for them)
>
> Closures :P.
>
>  
> Doh! I'm so retarded that I misspelled "generators" :(.
>  
> Apparently I've been reading too much about Ruby lately...


Not to worry :)
However the question stands, will Python support closures (or does it 
already via lambda expressions?)

(/me is lame at language theory)

- Sylvain
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/10/07, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:




Doh! I'm so retarded that I misspelled "generators" :(.



Hey, I'm all for getting support for both! :D



Apparently I've been reading too much about Ruby lately...



Haven't we all, Curt.  Haven't we all.. ;-)

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

Thanks for this, Dino!

On 7/10/07, Dino Viehland <[EMAIL PROTECTED]> wrote:


 That's our goal but unfortunately there isn't really much new in there
yet (from 1.1 w/ -X:Python25).  We have changed the default to having the
v2.5 features enabled now and no longer have a mode which runs as 2.4.



Major things we know we still have to do include yield expressions (sorry,
there's probably a technical term for them) and switching to new-style
classes for exceptions.  There's also a lot of random new functions added we
don't yet have.



*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] <[EMAIL PROTECTED]>.com<[EMAIL PROTECTED]>]
*On Behalf Of *M. David Peterson
*Sent:* Tuesday, July 10, 2007 12:17 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] Hosting IronPython 2.X in .NET app



On 7/6/07, *JoeSox* <[EMAIL PROTECTED]> wrote:


One of the reasons why I haven't updated IronTextBox is that
IronPython 2 is in Alpha.  I decided to wait until it was Beta.  On
top of that, Python is set for a major version upgrade soon, so I
don't know how this will effect IronPython's development.  I am
wondering if others are thinking the same?



I don't remember if it was a post to this list, or a blog entry, or a
white paper overview, or etc., but if not mistaken there is a considerable
amount of focus being placed on making IP 2.0 Python 2.5 compliant as well
as at least some effort at adding some of the Python 3000 features.



Can someone at MSFT verify?


--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | 
http://dev.aol.com/blog/3155


___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
/listinfo.cgi/users-ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>





--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/10/07, M. David Peterson <[EMAIL PROTECTED]> wrote:


On 7/10/07, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
>
> On 7/10/07, Dino Viehland < [EMAIL PROTECTED]> wrote:
> >
> >  Major things we know we still have to do include yield expressions
> > (sorry, there's probably a technical term for them)
> >
> Closures :P.
>


Are closures planned for Python 3000?



via a link from Sylvain >
http://www.artima.com/weblogs/viewpost.jsp?thread=208549 < I don't see any
mention of closures for Python 3000.

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Curt Hagenlocher]

On 7/10/07, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:


On 7/10/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
>
>  Major things we know we still have to do include yield expressions
> (sorry, there's probably a technical term for them)
>
Closures :P.



Doh! I'm so retarded that I misspelled "generators" :(.

Apparently I've been reading too much about Ruby lately...

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/10/07, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:


On 7/10/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
>
>  Major things we know we still have to do include yield expressions
> (sorry, there's probably a technical term for them)
>
Closures :P.



Are closures planned for Python 3000?

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Curt Hagenlocher]

On 7/10/07, Dino Viehland <[EMAIL PROTECTED]> wrote:


 Major things we know we still have to do include yield expressions
(sorry, there's probably a technical term for them)


Closures :P.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Dino Viehland]

That’s our goal but unfortunately there isn’t really much new in there yet 
(from 1.1 w/ -X:Python25).  We have changed the default to having the v2.5 
features enabled now and no longer have a mode which runs as 2.4.

Major things we know we still have to do include yield expressions (sorry, 
there’s probably a technical term for them) and switching to new-style classes 
for exceptions.  There’s also a lot of random new functions added we don’t yet 
have.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. David Peterson
Sent: Tuesday, July 10, 2007 12:17 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Hosting IronPython 2.X in .NET app

On 7/6/07, JoeSox <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:

One of the reasons why I haven't updated IronTextBox is that
IronPython 2 is in Alpha.  I decided to wait until it was Beta.  On
top of that, Python is set for a major version upgrade soon, so I
don't know how this will effect IronPython's development.  I am
wondering if others are thinking the same?

I don't remember if it was a post to this list, or a blog entry, or a white 
paper overview, or etc., but if not mistaken there is a considerable amount of 
focus being placed on making IP 2.0 Python 2.5 compliant as well as at least 
some effort at adding some of the Python 3000 features.

Can someone at MSFT verify?

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | 
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[M. David Peterson]

On 7/6/07, JoeSox <[EMAIL PROTECTED]> wrote:



One of the reasons why I haven't updated IronTextBox is that
IronPython 2 is in Alpha.  I decided to wait until it was Beta.  On
top of that, Python is set for a major version upgrade soon, so I
don't know how this will effect IronPython's development.  I am
wondering if others are thinking the same?



I don't remember if it was a post to this list, or a blog entry, or a white
paper overview, or etc., but if not mistaken there is a considerable amount
of focus being placed on making IP 2.0 Python 2.5 compliant as well as at
least some effort at adding some of the Python 3000 features.

Can someone at MSFT verify?

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[JoeSox]

On 7/6/07, Chris Parnin <[EMAIL PROTECTED]> wrote:
> I've seen several examples of how to embed IronPython 1.X in .NET.
> (e.g. IronTextBox) However, the architecture has changed greatly with
> 2.X.  Does anyone have a good example or pointers on hosting an
> interactive IronPython session in a .NET app?

One of the reasons why I haven't updated IronTextBox is that
IronPython 2 is in Alpha.  I decided to wait until it was Beta.  On
top of that, Python is set for a major version upgrade soon, so I
don't know how this will effect IronPython's development.  I am
wondering if others are thinking the same?
-- 
Later, Joe
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

[Chris Parnin]

I've seen several examples of how to embed IronPython 1.X in .NET.
(e.g. IronTextBox) However, the architecture has changed greatly with
2.X.  Does anyone have a good example or pointers on hosting an
interactive IronPython session in a .NET app?

Thanks,
Chris Parnin
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com