IronPython is Microsoft’s implementation of Python. It is being built simultaneously with the Dynamic Language Runtime, an infrastructure that allows dynamic languages to share code much in the same way the Common Language Runtime supports statically typed languages. Shri Borde discuses the status of IronPython 2 and how it works with compiled code.
Currently compiling IronPython to disk is temporarily unavailable. It was allowed in IronPython 1 and will return in the upcoming IronPython 2 Beta 4. This will be necessary if you want to reference the IronPython assembly from a statically typed language like C# or VB. It will also be needed when using reflection based tools like NUnit.
Another issue is that Python doesn’t have a way to support many CLS concepts. CLS, the Common Language Specification, is a subset of the full Common Type System and is considered to bare minimum needed for full interoperability. CLS compliant code excludes non-standard features such as VB’s optional parameters and C#’s unsigned integers.
IronPython has trouble producing CLS complaint code because there is no way to express concepts like visibility (Public vs. Private), parameter and return types, or custom attributes. Extensions to the language could be made, but at the cost of losing compatibility with other Python runtimes.
In the short term, hosting the DLR and thus IronPython, from an application written in VB or C# looks promising. As does building the base classes in those languages and extending them with IronPython code. Over the long run, possible enhancements such as the ability to make late-bound calls in C# without explicit reflection logic should prove beneficial.