[IronPython] IronPython status
andy_somogyi at hotmail.com
Tue Feb 22 19:22:13 CET 2005
I did take a look at Boo, hoping to use some code / ideas of thier
It is kind of an interesting implementation, they seem to be very fond of
classes where each one has very little functionality by itself.
Also, part of the Boo implementation is in c# and the other part is in Boo.
I am really
not fond of interpreters written in the interpretting language. I think the
CPython / Jython / IronPython approach is MUCH better, faster, more stable
and easier to follow.
Also, I am not very fond of 'like' languages, i.e. a 'C' like language or a
like language, or in this case a 'Python' like language.
I like IronPython because it IS Python, not 'like' Python. Also, IronPython
is well designed and it is fairly easy to follow and understand the code.
The syntactic and semantic portions of IronPython are nearly perfect, it
has a well consturcted recursive descent parser that generates a tradational
The runtime portion of IronPython just needs some work.
With my 'fork' of IronPython, I'm implementing the runtime slightly
Currently, all python objects are of a type called 'DynamicType'. When a
.net assembly is imported, all the types are wrapped in a derivitive of
Now, the .net runtime allready supports the features of this type via the
So, what I am going to do is this: All Python types will implement the
optionally the IExpando interface. Python functions will extend the standard
interface. Then all generated code will operate on these standard
The advantage is that .net assemblys can be imported directly, without
having to wrap
the types in a python type, and all Python objects can be visible to
using the standard reflection interfaces.
The other nice thing about the MethodInfo interface is that in .net 2.0
there is a
new feature called 'lightweight code generation': Basically, you can create
fully dynamic method. This new method is not part of a type, and can be
collected like any other .net object. So, the .net 'DynamicMethod' type
the 'MethodInfo' interface, and when IronPython moves to .net 2.0, the new
lightweight code generation features can be seamlessly added.
>In the meanwhile, I would suggest a look at Boo, a great new CLR language
>(http://boo.codehaus.org/). It's not Python, but very similiar. It lacks
>some of the more dynamic features of Python, but compensates well for that
>in other areas. And it works, today. I might even prefer Boo to IronPython
>even if IronPython should reach a more mature stage.
>----- Original Message ----- From: "Ryan Williams" <ryan4096 at bellsouth.net>
>To: <users-ironpython.com at lists.ironpython.com>
>Sent: Tuesday, February 22, 2005 1:15 AM
>Subject: Re: [IronPython] IronPython status
>>Personally, I think it's great that someone wants to work on it. I
>>really like the idea of IronPython, and have been disappointed to see
>>the current lack of activity.
>>On Fri, 2005-02-18 at 13:52 -0700, Andy Somogyi wrote:
>>>As I have not seen much updates on IronPython recently, and I believe it
>>>a superb product and tremendous potential, I have recently begun the
>>>of looking for and fixing bugs in the IronPython distribution.
>>>So far, I have fixed the issue with a module not storing the __name__
>>>attribute properly, eval not parsing input string correctly, and the map
>>>function not working when given more than 2 arguments.
>>>If Jim has no objections, I have created a CVS repository with all the
>>>Also, if Jim has no objections, you can submit bug reports at:
>>>I have also started documenting IronPython, and I will be producing ndoc
>>>generated help files.
>>>users-ironpython.com mailing list
>>>users-ironpython.com at lists.ironpython.com
>>users-ironpython.com mailing list
>>users-ironpython.com at lists.ironpython.com
>users-ironpython.com mailing list
>users-ironpython.com at lists.ironpython.com
More information about the Ironpython-users