[IronPython] Kamaelia and IronPython (was: Hosting IronPython 2.X in .NET app)

[M. David Peterson]

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


 Very cool!



Yup :)

And I guess this means we have a bug relating to not that we need to figure

out in v2.0 J.



Yup :D  But none-the-less, the fact that this works thus far on 1.1 (and at
some point in the future on 2.0) opens up some exciting possibilities in
regards to gaining the concurrency benefits that the underlying Axon library
provides while at the same time the ability to build some Kamaelia
components for IronPython that take full advantage of all of the underlying
feature set.  Off the top of my head, extending the IronTunes sample (@
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Samples&referringTitle=Home)
to incorporate P2P audio streaming ( e.g. personal radio stations that you
could then access from another web-enabled device) would be a fun project.
And integrating MonoTorrent into the mix (which is now *EXTREMELY* fast and
reliable (see: http://monotorrent.com/) should present some interesting
opportunities to mimic some of the C-based extensions that wouldn't work via
IP.

Michael: Have any project ideas for extending Kamaelia into the .NET realm?
What about tutorials for folks wanting to get their feet wet with Kamaelia?

To everyone else, there's a Kamaelia Cookbook[1] and a recently added Ideas
page[2].  From my own experience, Kamaelia is both fun and exciting to work
with once you realize how much power is at your fingertips.

[1] http://kamaelia.sourceforge.net/Cookbook
[2] http://kamaelia.sourceforge.net/Developers/Ideas

--
/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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[Dino Viehland]

Very cool!  And I guess this means we have a bug relating to not that we need 
to figure out in v2.0 ☺.

From: M. David Peterson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 3:55 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Dino Viehland; Discussion of IronPython
Subject: Re: [Kamaelia-list] [IronPython] Hosting IronPython 2.X in .NET app

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

I'll add Kamaelia to the same repository folder now and see where that leaves 
things.

Done and,

IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import Kamaelia
>>>

This is exciting to see!  Any tips on where to start playing to test for low 
level compatibility with both Axon and Kamaelia?

--
/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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[M. David Peterson]

On 7/10/07, Ken Manheimer <[EMAIL PROTECTED]> wrote:



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.



Ugg!  Hey Curt, we're now twins! ;-)

Yep, I most definitely confused things here.  Thanks for the correction!

(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.)



Yep. this all makes sense.

i couldn't resist this clarification, and hope i haven't mistaken what you

were saying (or, what i'm saying:-).



Nope, you are right on the money.  I said closures, but meant
continuations.  Thanks for correcting me!

--
/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

[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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[M. David Peterson]

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



I'll add Kamaelia to the same repository folder now and see where that
leaves things.



Done and,

IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.

import Kamaelia



This is exciting to see!  Any tips on where to start playing to test for low
level compatibility with both Axon and Kamaelia?

--
/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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[M. David Peterson]

It just occurred to me that you could just as easily use IronPython
Community Edition r6 (based on IP 1.1) as the IP2.0 features shouldn't be
required to test for compatibility.

With the above in mind,

svn co http://extf.googlecode.com/svn/vendor/IPCE-r6/
cd IPCE-r6
mono ipy.exe -X:TabCompletion -X:ColorfulConsole

results in the following,

IronPython 1.1 (1.1) on .NET 2.0.50727.42

Copyright (c) Microsoft Corporation. All rights reserved.
>>> import Axon
>>>



Which I believe is a good sign ;-)

I'll add Kamaelia to the same repository folder now and see where that
leaves things.

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


On 7/10/07, M. David Peterson <[EMAIL 
PROTECTED]>
wrote:
>
>
> I'll compile the binaries for use on GNU/Linux/Mono, add them to the
> repository, and send you the link when complete.


Ran into some strange compilation errors so am rebuilding Mono from SVN to
see if this fixes them.  Will take a bit longer than I thought before this
is ready.

--
/M:D

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





--
/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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[M. David Peterson]

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



I'll compile the binaries for use on GNU/Linux/Mono, add them to the
repository, and send you the link when complete.



Ran into some strange compilation errors so am rebuilding Mono from SVN to
see if this fixes them.  Will take a bit longer than I thought before this
is ready.

--
/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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[M. David Peterson]

Hi Michael,

I've added all of the necessary module dependencies as well as Axon
1.5.1into the SVN repository @
http://extf.googlecode.com/svn/vendor/IPCE-r6/Lib/ < This includes various
standard lib modules such as sets that I pulled from Python 2.3.6.

I just checked, and IPY2 Alpha 2 wont run via Mono as is (requires a couple
of patches from Seo to build properly), so I will need to quickly compile a
fresh set of binaries for you to test with.  In the mean time, on Windows,
here's what I am currently looking at from within an ipy.exe session (using
a checked-out Lib directory from above)

IronPython console: IronPython 2.0A2 (2.0.10627.00) on .NET 2.0.50727.1318

Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.path.append('.\Lib')
>>> import Axon
Traceback (most recent call last):
  File , line 0, in ##11
  File , line 0, in _stub_##2
  File .\Lib\Axon\__init__.py, line 32, in Initialize
  File , line 0, in _stub_##145
  File C:\Documents and Settings\M. David\My
Documents\Projects\Lib\Axon\Scheduler.py, line 67, in __init__
  File , line 0, in _stub_##52
  File C:\Documents and Settings\M. David\My
Documents\Projects\Lib\Axon\Microprocess.py, line 229, in __init__
  File , line 0, in _stub_##52
  File C:\Documents and Settings\M. David\My
Documents\Projects\Lib\Axon\CoordinatingAssistantTracker.py, line 45, in ge
tcat
  File , line 0, in _stub_##103
  File , line 0, in _stub_##329
TypeError: unsupported operand type for Not:
'coordinatingassistanttracker'



I'll compile the binaries for use on GNU/Linux/Mono, add them to the
repository, and send you the link when complete.

On 7/10/07, Michael Sparks <[EMAIL PROTECTED]> wrote:


On Tuesday 10 July 2007 21:25, Dino Viehland wrote:
> Does Kamaelia use the new syntax as supported via PEP-342

Kamaelia uses the simpler version of generators which rather than the new
functionality in PEP342. Specifically Kamaelia uses the version of python
generators that has been part of the language since python 2.2.2 -
specifically PEP 255 generators:

cf http://www.python.org/dev/peps/pep-0255/

Personally I'd be surprised if Kamaelia didn't work on IronPython, but
I've
simply not tried it myself. If someone tells me the dependencies under
Linux,
I'd be more than happy to test it :)


Michael.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Kamaelia-list mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kamaelia-list





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



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] [Kamaelia-list] Hosting IronPython 2.X in .NET app

[M. David Peterson]

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


 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.



I believe that Kamaelia is compliant with Python 2.4 forward.



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 should have clarified.  Axon is the underlying concurrency framework, and
if not mistaken, is written in pure Python.  I believe Kamaelia (which sits
on top of Axon) in and of itself is written in pure Python, but the plugins
are heavily built upon the C-based extension API.  I'll dig deeper and find
out for sure.  I'll also attempt to get Axon running via IP and report back
the result.

Thanks for your help, Dino!

--
/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]> 
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]
>>> > 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
>> 
>
> 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]
> > > 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

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
/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]> 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