The new plan is to release every two weeks until there is a 1.0 release. There are one-and-a-half engineers working on IronPython. Jim is spending half his time evangelizing dynamic languages and Python within Microsoft. The hope is that the next version of CLR will have better support for dynamic languages (although it's not at all clear to me what that means).
The talk was basically the same as the talk he gave at Lightweight Languages in December, but stretched out to an hour. There was time for more demos and more technical detail.
Jim claims two advantages for Python running on .NET: It provides easy access to .NET libraries, and it leverages a substantial engineering effort on the .NET VM. He showed his standard demo using msagent. The demo crashed: "Look at this beautiful stack trace." He has used this demo to introduce people to Python, like C# programmers. The interactive interpreter has left the biggest impression on people.
On the other hand, he has seen C# programmers write this as their first Python program:
from System import *
He also had a demo of an Avalon GUI in Python. The basic demo was
trivial -- window, title, button. Jim was droll: "Doesn't that make you drool?
Don't you want to lick my screen?" He showed a xaml-generated GUI and
wrote some code to walk over the GUI objects -- basic introspection
and modification of individual widgets.
By relying on the .NET VM allows the IronPython implementation to stay
simple. IP 0.7 is about 80% faster than Python 2.4. The IP
implementation doesn't make any particular effort at optimization. It
has a straightforward code generator. From the bytecode, it looks
very much like Jython: use static fields in generator code for
constants, call into runtime implemented in C# for most real
operations -- "==" op calls "IronPython...Ops::Equal".
Guido asked: The generated x86 is somewhat larger than the Python bytecode.
Does the increased size cause worse cache performance? more misses
when you run the larger code?
Jim's answer: Based on experimental evidence, this isn't a problem. Memory
pressure is an issue in general, but he doesn't have any evidence that code size is the problem. The current IP implementation uses a lot more memory than CPython.
The next demo was loading a C# assembly into IP and calling a static method. The audience asked him to call a Python function from C#. He was entertainingly nervous about getting this part of the demo to work. He got a big round of applause when the demo worked. He passed a Python function into C# and had it called.
Next showed the debugger integration. The debugger shows a mix of IP implementation code and Python code. You can introspect on values in either language. The profiler works the same way, he said.
The standard for long-term compatibility is Jython. IP ought to run the same set of regression tests as Jython.
Some of the hard integration problems:
- Can all strings by unicode? (Guido: Fine with me.)
- What is the right locking policy? There's no GIL in IP, so what kind of concurrency should the builtin types allow.
- Can we experiment with optional static types?
- How to expose CLR-style methods on both Python types and on existing CLR types? For example, should a CLR ArrayList have an append() method like Python?