IronPython URLs

Another collection of blog entries and projects related to IronPython and the Dynamic Language Runtime. IronRuby 0.9 starts 6 times faster than IronPython 2.6B1, why is that? Does anyone know? IronPython 2.0 is significantly slower to start than CPython, which is an issue for those writing command line tools and full applications in IronPython. IronPython 2.6 improves the situation, but as the lament in this short blog entry expresses it is still slow even when compared to IronRuby: IronRuby 0.9 starts 6 times faster than IronPython 2.6B1 Why is that? Don’t they use the same DLR engine? If IronPython started the same way, probably I would not use ‘CPython plus .Net exposed through MSFT Com’ technique. It is just unfair. On the usual support channel ( Twitter ) Dino Viehland explained that the IronPython interpreter does a bunch of work at startup time that IronRuby doesn't. On startup the interpreter imports the site module site just like CPython (and IronPython uses site.py from ...

Harry Pierson (DevHawk) has an interesting article on dynamically compiling C# from IronPython using CodeDom . His motivation for this is to allow him to use extension methods without tying himself into a dependency on a specific version of the DLR. IronPython and CodeDOM: Dynamically Compiling C# Files Of course, I could have simply re-compiled the assembly against the new bits, but that would mean every time I moved to a new version of IronPython, I’d have to recompile. Worse, it would limit my ability to run multiple versions of IronPython on my machine at once. I currently have three – count ‘em, * three * – copies of IronPython installed: 2.0 RTM, nightly build version 46242, and an internal version without the mangled namespaces of our public CodePlex releases. Having to manage multiple copies of my extension assembly would get annoying very quickly. Instead of adding a reference to the compiled assembly, what if I could add a reference to a C# file directly? Kinda like how addin...

I've got a backlog of links to post; normal service will be resumed shortly... In the meantime here a few snippets that may be of interest. Through the ' Pyc ' compiler sample, which uses ' clr.CompileModules ' under the hood, IronPython 2 can compile Python code to binary assemblies. These assemblies can be ngen'd (pre-JITed) making imports roughly three times as fast as from a Python sourcecode file. This is great because IronPython import performance is sloooow... In the latest beta (2 beta 5) compiling packages was broken, meaning that we couldn't build and test a binary distribution of Resolver One running on IronPython 2. This problem was supposed to have been fixed in the latest codeplex source code drop , so today I tested it out. The first thing I had to do was build IronPython 2 from sources on a machine that has .NET 3.5 installed, but not Visual Studio 2008. It took me a while to find precisely the right magic command line invocation to build in ...

One of the headline features in the new IronPython 2.0 Beta 4 release is that static compilation is back. IronPython is actually a Python compiler, it compiles Python code to in memory assemblies (that can then be JITed like any other .NET assembly). In IronPython 1, these assemblies could be saved to disk (as .exe or .dll files) and then imported from like normal Python files. This was the IronPython equivalent of CPython's 'pyc' compiled bytecode files. UPDATE: The new 'pyc.py' sample demonstrating static compilation for IronPython 2 is now available for download . This feature is curently used by Resolver Systems to do binary only distributions of Resolver One . It was initially missing from IronPython 2, and for a while it looked like it wouldn't make it back again - but thankfully it has now returned. This makes the transition for Resolver One from IronPython 1 to IronPython 2 (once it out of beta) an easier one - although the Resolver One codebase is heav...

With IronPython it is possible to dynamically compile C# to in-memory assemblies and access them from the running application. This can be used to access attributes, not normally available to IronPython - as well as many other tasks. Dynamically Compile C# from IronPython

Antonio Cuni has just announced CarbonPython: CarbonPython - aka C# Considered Harmful CarbonPython is an RPython compiler for .NET, which can statically compile a subset of Python (Restricted Python) . The resulting assemblies can be used from IronPython and C#. You can also read my summary of the project.

Jim Hugunin has posted another blog entry: DLR Trees (Part I) This is about how the DLR builds language trees (an AST or CST I guess?) for representing dynamic languages. These are unlike the trees that C# compilers use because they are untyped (and unbound). "The value of having dynamic languages target this tree form is that we can perform lots of optimizations in the DLR layer on behalf of the language implementations."

Gary Stephenson announced OxIDE, a compiler for Xbase++ into IronPython. http://www.oxide.net.au/