IronPython URLs

If you're part of the Python community then it may well have passed you by that a major new release of the .NET framework is imminent. .NET 4.0 is a new version of the Common Language Runtime (CLR), unlike 3.0 and 3.5 which were primarily new libraries and language enhancements for C# and VB.NET. A big part of .NET 4.0 is the Dynamic Language Runtime (DLR), on which IronPython and IronRuby are both built, and parts of the DLR are moving into the core .NET. This enables the introduction of the dynamic keyword in C# 4.0 and VB.NET 10. One of the major use cases for the dynamic keyword is to make it easier to integrate dynamic languages with the statically typed ones, for embedding or for hybrid applications. A minor addendum to the new .NET 4.0 is Visual Studio 2010. .NET 4.0 Beta 2 is the second beta (Community Technology Preview - CTP) of both .NET 4.0 and Visual Studio 2010. To go with this CTP there are new releases of both IronPython and IronRuby. IronPython 2.6 CTP for...

Another collection of blog entries and articles related to IronPython and the Dynamic Language Runtime. IronPython 2.0.3 Must Fix Bugs With IronPython 2.6 Release Candidate 1 out of the door you might think that IronPython 2.0 was already defunct. Not true! David DiCato, an IronPython core developer, just posted to the IronPython mailing list asking what bugs people would like to see fixed in a 2.0.3 release: As we work towards our IronPython 2.0.3 bugfix release, Dino and I would like to get a feel for which bugs left unresolved in 2.0.2 are most important for us to fix in the next release. Please let us know ASAP if there’s an issue you’d like to see fixed in IronPython 2.0.3. Thanks! IronPython unter Eclipse 3.5 mit PyDev - Veni, vidi, vici  A blog entry (in German with just a hint of Latin) from Rainer Schuster about how he bent Eclipse 3.5 (with PyDev ) to his will for IronPython development. Google translate reveals his conclusion: From now on you is CodeCompletition ...

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 ...

Jon Skeet, author of the well regarded C# in depth , did a five minute talk on C# 4.0 and the Dynamic Language Runtime at a recent Google Open Source Jam in London. The 'innovative' slides are online, and they touch on details like the dynamic keyword, binders and IDynamicMetaObjectProvider . OS Jam at Google London: C# 4 and the DLR The fundamental point of the DLR is to handle call sites - decide what to do dynamically with little bits of code. Oh, and do it quickly. That's what the caches are for. They're really clever - particularly the L0 cache which compiles rules (about the context in which a particular decision is valid) into IL via dynamic methods. Awesome stuff. I'm sure the DLR does many other snazzy things, but this feels like it's the core part of it. At execution time, the relevant binder is used to work out what a call site should actually do. Unless, that is, the call has a target which implements the shadowy IDynamicMetaObjectProvider interfa...

The new dynamic keyword in C# 4.0 is made possible by including the Dynamic Language Runtime in the .NET framework. The DLR was originally part of the first implementation of IronPython and was abstracted out in order to create a framework for implementing dynamic languages on .NET. Further than that, the DLR has been used to introduce new features into C# and VB.NET, the static languages traditionally used to program .NET. This is seen as a major part of what is new in .NET 4.0. When Jim Hugunin went to work at Microsoft he wasn't employed to work specifically on IronPython; he joined the CLR (Common Language Runtime) architecture team with the brief of helping to make .NET a better runtime for dynamic languages. What follows is largely as the result of his influence and work. The full semantics of the dynamic keyword are laid out in the C# 4.0 language specification document. C# 4.0 Specification Document Note that this document is for the beta version of .NET 4.0. Although the ...

This post is a bit late - in fact this news was announced several months ago at this year's Microsoft Professional Developer's Conference . At the PDC the Dynamic Language Runtime was demonstrated - along with the news that it will be part of .NET 4.0. Both Visual Basic 10 and C# 4.0 will have dynamic elements that make use of the Dynamic Language Runtime. In a blog entry after the conference Jim Hugunin links to Channel 9 videos of his talk on the DLR and Anders Hejlsberg's talk on the way C# is changing. Dynamic Language Runtime Talk at PDC C# 4 will allow you to use objects dynamically through a new static declaration. A new keyword that allows you to statically declare dynamic objects! Objects that are declared as dynamic will have operations on them (attribute lookups, method calling, indexing, numerical operations and so on) done through the DLR. The intarwebz were awash with the news. Here is a selection of the most interesting and informative responses that I foun...

Mark Bloodworth (a Microsoft Architect Evangelist no-less!) posts a code snippet showing how to execute Python code from C# with the IronPython hosting API: Running Python from C# Embedding IronPython in .NET applications (or even embedding new Python engines in IronPython applications) is extremely simple to do. This means that providing user scripting, or even making part of an application dynamic, is much easier than it ever has been. Mark says: " I’m impressed that C# and IronPython can interact like this. The possibilities for extending applications with runtime dynamic code are intriguing - worth looking into. "

Python has very useful constructs for accepting variable number of positional and keyword arguments: def f(*args, **keywargs): pass The arguments are collected as a tuple and a dictionary. C# can collect an arbitrary number of arguments to a method (no messy functions in this language!) as an array (with the params keyword) - but it has no concept of keyword arguments let alone collecting them as a dictionary. In this blog entry Srivatsn (IronPython tester) introduces the ' ParamDictionaryAttribute ' that is part of the Dynamic Language Runtime ane explains how to use it to write C# classes that can take arbitrary number of keyword arguments: Passing Keyword Args to C# Methods from IronPython

A channel 9 video interview with Anders Hejilsberg and the C# design team on the future of C#, specifically C# 4.0. The team (and video) includes Jim Hugunin (creator of Jython and IronPython) and the discussion rambles around language design issues, the importance of concurrency, and how dynamic languages are influencing C# and the Common Language Runtime. The video is an hour long (and the high quality version around 950mb to download), but very entertaining - although Anders doesn't seem to realise that there are plenty of IDEs for dynamic languages with capable intellisense features. C# 4.0: Meet the Design Team From the introduction to the video: C# 4.0 will contain many new features that will help developers be, yeah, you've heard it before, more productive. There's also some very interesting work going on with adding dynamic constructs to the language, which is of course very interesting given the static nature of the C# language. In this video you will not get any s...

Dare Obasanjo continues his exploration of IronPython by exploring it to C# 3: Does C# 3.0 Beat Dynamic Languages at their Own Game? C# 3 has several new features, that even if not directly inspired by Python, will seem very familiar to Python programmers... Dare concludes: I love the REPL, I love the flexibility that comes from having natural support tuples in the language and I love the more compact syntax. I guess I’ll be doing a lot more coding in Python in 2008.

A blog entry by 'Coding the Markets' on wrapping a "C# WinForms object in a Python dictionary". Calling IronPython from C# Using Delegates

A Code Project article on embedding IronPython (1.1 from the looks of it) in a C# WPF application: Embedding IronPython in WPF C#

I previously blogged about how to use the IronPython engine from inside a compiled C# Silverlight assembly. This worked fine when you used the resulting assembly from IronPython , but not when used standalone! This was due to a bug in the platform assumptions that the DLR makes, but with help from the IronPython mailing list a workaround has been found: Embedding IronPython in a Silverlight (C#) Application It means a bit of extra boilerplate code, but hopefully before Silverlight 1.1 final this code will have moved into the DLR and all will be rosy again... Oh, and by the way... IronRuby is now Live on RubyForge . John Lam has build instructions and news on the latest updates on his blog .

A blog entry, by Saveen Reddy, comparing IronPython and C# 3.0 code side by side, using Notify Icon from the IronPython Cookbook as the example: C# 3.0 as Python with Braces Of course Python with braces isn't Python, but it could be worse...

There have been several new entries in the IronPython cookbook recently: The IronPython 2 Parser - An example of using the IronPython 2 Parser API to extract the variable names used in a Python expression. Screen Capture - Taking a screenshot from IronPython with Windows Forms. Using Python Functions from C# - An example of embedding IronPython 2 in C# that creates IronPython functions and calls them from C#. A while ago Andrzej Krzywda posted an example of downloading web pages with IronPython. It turns out that the examples can be made even shorter. See Accessing the Web with IronPython for details. The IronPython Cookbook Downloading a Web Page recipe has been appropriately updated.

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

drifter46and2 shares some code: A class to compile and import csharp code embedded inside of a python module Ironpython command shell embedded in window textbox http://drifter46and2.livejournal.com/3226.html

An example of creating delegates and predicates at runtime rather than compile time. http://www.base4.net/Blog.aspx?ID=118

Another interesting post from Fuzzyman . He explains how to do the following: Taking a screenshot with IronPython Creating a class in C# and using it from IronPython Using unmanaged code from IronPython and C# http://www.voidspace.org.uk/python/weblog/arch_d7_2006_10_28.shtml#e530