IronPython architecture

Chris and I met with Jim Hugunin this morning and got an overview of the IronPython architecture.  Which is basically, very simple and straightforward.  Like you might expect, it consists of a tokenizer, a parser, a code generator and a library of built in functionality.  The code generator simply emits IL...hence the big advantage of implementing Python, or any language, on top of .NET:  you don't have to write your own interpreter or VM.  Not only did this make Jim's work easier to begin with, but he takes advantage of the continual work of the CLR team.  For example, on a typical benchmark IronPython on .NET 2.0 is 10-20% faster than it was on .NET 1.1...and all Jim had to do was re-compile (in the example he told us about, it was improvements to delegate perf that made the difference).

With so much of the code generation work done for him, the largest part of the IronPython code base is the library.  Of course, another big advantage of Python on .NET is access to the Frameworks library.  And here is where some interesting issues come up.  A Python programmer would expect to be able to call .append() on any collection to add things.  Should this work on List<T>?  Conversely, what if a Python built-in method has a name conflict with something on a .NET class?

Comments

• Anonymous
  May 18, 2005
  Doesn't J# get around the name conflict by having its own namespace for J#-specific bits?
  
  I can easily see a IronPython namespace, including IronPython.Collections.List.