Saturday, June 27, 2009

The IronRuby Tutorial

Jimmy Schementi, program manager for the dynamic languages and Silverlight integration plus IronRuby developer, has pushed a new update to the IronRuby github repository.

One of the major changes is improvements to the IronRuby tutorial app.
As you can see from the screenshot this is a WPF (Windows Presentation Foundation - which means it won't run on Mono) application which combines a tutorial with an integrated interpreter (REPL) for actually trying out the code:
Isn’t he/she/it a bute!? This app makes Ruby-based tutorials interactive, guiding you through the material with a IronRuby REPL console and other visual aids such as another window, or whatever the tutorial writer sees fit. There is also a tutorial runner for the command-line, and a exporter for static HTML.

The IronRuby tutorial included covers topics such as using the interactive window, built-in libraries, exploring .NET libraries, generics, events, Windows Forms, and Windows Presentation Foundation.
I'm highly envious of this for IronPython and it was always my intention to turn TryPython into something similar, but using Silverlight. With Silverlight 3 / Moonlight it could run in the browser or out of it. Who knows, I may still do it...

OS Jam at Google London: C# 4 and the DLR

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.
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 interface (winner of "biggest mouthful of a type name" prize, 2009) - in which case, the object is asked to handle the call. Who knows what it will do?

Friday, June 26, 2009

New JavaScript Implementation for the DLR

The Dynamic Language Runtime was announced at the same time as Silverlight. Along with IronPython and IronRuby a third, Silverlight only, language was announced that ran on the DLR.

This language was Managed JScript, an ECMA compliant version of Javascript that was touted as an easy way to port AJAX applications to run on Silverlight.

Unfortunately as IronPython and the DLR developed Managed JScript stagnated. It was only ever released as binaries and hasn't been kept up to date with recent versions of the DLR. Someone called it the Bastard, red-headed step-child in the DLR.

However, there is now an alternative implementation of JavaScript for the DLR:
RemObjects Script for .NET is an embeddable engine for .NET applications that allows developers to let their users introduce written scripts that influence the behavior of the application.

The RemObjects Script engine is built in a language-agnostic way, so that different concrete language implementations can be created on top. It currently supports most of ECMAScript 262 version 1.5 (also known as JavaScript). There are also plans to support Pascal Script.

It's based on the Microsoft DLR runtime for simplicity and ease of inter-operability with other dynamic languages and .NET 4.0 languages with support for dynamic operations, but can be run on any version of .NET 2.0 or later, as well as Mono.

Currently supported features:
  • Objects
  • Prototypes
  • Functions
  • Arrays
  • Booleans
  • Regular Expressions
  • Numbers
  • Build-in classes: Object, String, Function, Array, Number, RegExp, Date, Boolean
  • Interopability with non-ECMAScript types
  • Interopability with other DLR-based language types
ECMAScript is a dynamic language and is weakly typed. It uses a prototype based object model (no classes). It is a flexible language that due to its lack of types is ideal for scripting purposes. EMCAScript has a very simple model for object oriented programming, where objects are property bags with a "prototype" model to allow for a way of inheritance. It supports closures (nested functions) and every function is an object on it's own.

Note: RemObjects Script is in early development stages, and currently only available from its SVN source control repository at code.remobjects.com. It is implemented using Delphi Prism and the Oxygene language.

Twisted on IronPython

One of the big new features coming in IronPython 2.6 is optional support for Python stack frames (with a ~10% performance hit tracking the frames if it is enabled).

With this in place Seo Sanghyeon, maintainer of FePy the community distribution of IronPython, has been looking at getting Twisted working with IronPython. Twisted is an open source event-driven networking engine written in Python.

Seo posted this email to the IronPython mailing list:
I have started porting Twisted to IronPython.

Progress is to be tracked on this Trac ticket.

There is a Buildbot running the Twisted tests with IronPython.

Just in case you don't know, Twisted is an event-driven networking engine written in Python licensed under MIT license, which aims to destroy the American currency system. See following links for more details.
Having frame support in IronPython opens up the possibility for Python debugging APIs, like sys.settrace, being implemented in IronPython.

A recent checkin to the public source code repository had this in the commit message from Dino Veihland:
Adds the in-proc debugging support that Igor as been working on. This adds a new DLL to the IronPython MSI and to the IronPython and DLR CodePlex releases.

This is just adding their source code and updating our build and packaging infrastructure to include their new DLL. The only changes to their code were some #ifdef’s to support Silverlight builds and some updates to the .csproj files to support our numerous builds. This code is owned by them and has been reviewed by their team so I’m not looking for a code review for the new DLL.

Once this is in I’ll be updating Igor’s prototype for sys.settrace support for IronPython and adding that.
Cool...

Thursday, June 25, 2009

NWSGI: New release and big improvements

NWSGI is "a .NET implementation of the Python WSGI specification for IronPython. It is implemented as an ASP.NET HttpHandler for use with IIS 6 and 7" created by Jeff Hardy. The goal is to be able to run Python applications like Django, Trac and Pylons on IronPython. It can also be used on the Microsoft Azure (cloud computing) platform.

Jeff Hardy has just released a beta of version 2.0, and explained the new features:
This is a major update to NWSGI that makes it easier to install and use and dramatically improves the management story.

So, what happened to 1.1? Originally, NWSGI 1.1 was going to be a refresh of v1.0 that supported IronPython 2.6 and fixed a few bugs. NWSGI 2.0 was going to completely overhaul large parts of the management UI and make some deeper changes to the handler itself. However, I got a week off with some rain and v2.0 progressed much quicker than expected; v1.1 was obsolete before it was even released.

So, v1.1 was dropped and v2.0 will be the first IronPython 2.6-compatible release. It’s easy to make breaking changes when you have no customers.

What’s New
  • Easier configuration. In v1.0 there were different ways to configure NWSGI depending on your configuration. Now there is only one way to do it. Some of the more ambiguous options have also been cleaned up, and new ones added to support IronPython 2.6.
  • Better management UI. IIS 7 includes a rich UI framework for developing management extensions, but doesn’t have much documentation on it. Some spelunking with reflector showed me better ways to do pretty much everything; not much of the v1.0 management code is left.
  • Performance improvements. NWSGI will now cache the WSGI callable instead of reloading it each time.
  • Other misc. fixes. I really need to get into the habit of adding a Codeplex issue for each bug so that I can keep track of what I’ve fixed.
Jeff has also made two separate blog entries explaining the major changes.
There are two ways to use NWSGI: by installing it or by using xcopy deployment. Each method has its advantages and disadvantages, but their functionality is the same.
One of the two areas to see the most changes in NWSGI 2.0 was its configuration. Some of the options in v1.0 were overloaded in strange ways; even I wasn’t entirely sure what some combinations would produce. There was also the small problem of where to put the configuration section; it varied depending on how NWSGI was installed. For v2.0, both problems needed to be fixed. Doing so required a re-think of how configuration was handled.

Choosing a DLR language: IronPython or IronRuby?

.NET developers interested in dynamic languages but still wanting to stay within the .NET ecosystem have an interesting choice - IronPython or IronRuby?

Simon Segal, who has been adding scripting support to his Entity Framework profiler, has been pondering this question:
For my part so far I have delved into IronRuby and started to employ it for scripting my C# applications. Why did I choose IronRuby over IronPython? It began with curiosity in the Ruby language in general and led inevitably to IronRuby. I quickly acquired a taste for Ruby but there is something nagging in the back of my mind and I can’t get to the bottom of it - “did I choose the right language” and really after all “does it matter which one I choose?”

Given Pythons relationship to C and my emotional connection to the C family of languages, would IronPython have been a better choice? Certainly IronPython is further down the track and more mature than IronRuby at this stage, but what does that count for at this early stage? All these questions make me curious for some other opinions which I would leave to hear right here, so please tell me – what do you think? What criteria would you use to make a choice?
Shortly after he chose IronPython over IronRuby:
After having spent a less than insignificant amount of time invested in IronRuby I decided to bite the bullet and invest the effort into IronPython instead and the reasons were entirely pragmatic. Microsoft seem to be putting more effort into IronPython, has already found it’s way into other stacks, such as Oslo’s Intellipad (which I plan to leverage) and it’s significantly more mature than IronRuby.

I am constantly finding uses for IronPython in my work and the list of problems that it’s going to help solve is growing quickly. As a side note, if you are looking to use IronPython and are ready to let the experience pass you by because of lack of IDE support then check out using NetBeans (for Python) and instead using IronPython.
Prior to writing these blog entries Simon contacted me by email and asked me what I thought.
I have been investing some time of late with IronRuby and have started several projects that incorporated scripting into applications written in C# and also have begun a project for a Entity Framework profiler that allows for scripting of my Repositories.

My question is regarding what I feel is a choice right now between IronPython and IronRuby. I am increasingly feeling a bit anxious that IR is slowing me down because of the projects maturity as compared to IP and I am also getting the impression that IP is somewhat preferred within Microsoft itself? I have no experience with Python but feel that if my chosen dynamic language in the .NET space needs to change it should be sooner and not later. I am not looking for a lengthy bullet point IR vs. IP evaluation, just a short high level opinion as to whether my concerns or any others should be heeded. If IP is the way to go I think I know of a good book!

My thoughtfully considered and entirely unbiased response...
I'm sure you don't expect an unbiased opinion from me, so I assume you have already made your decision and just need me to push you over the edge. ;-)

Actually IronRuby is approaching a 1.0 release soon, so it sounds like it is improving as regards maturity.

Despite this IronPython is more mature as regards .NET interop, performance and bugs. Version 2.6 will be a particularly good release (lots of work on performance) including features like __clrtype__ allowing the use of .NET attributes that I think will take a while before they show up in IronRuby.

Personally I think there are lots of reasons to prefer IronPython over IronRuby:

The Python object model is much closer to C# than Ruby. This means that it performs better and there are less issues around .NET interop - plus it is easier to learn for C# developers.

Python in general is a 'cleaner' language (a purely aesthetic judgement) with clearer namespacing, less use of sigils and no syntactic dependence on the casing of class / variable names. Although Ruby has anonymous blocks they are highly special cased in the language leading to various anomalies in the way they are handled. It is still annoying that Python can't have statements in its lambda functions but there is no clear way to add them to the language (due to using indentation for block structure which despite this disadvantage is still a stroke of genius).

Because Python is more widely used (still - despite all the publicity that Ruby has had through Rails in the last two years or so) there is wider community and more open source libraries available.

Having said all that, both Python and Ruby are great dynamic languages in which it is easy to be productive. They have different facilities for metaprogramming but as far as I can tell they are both equally powerful. Either choice would be a good one but naturally I think Python is the better choice...

Wednesday, June 24, 2009

IronPython Performance: On Mono, on x64 and compared to C#

Everyone loves benchmarks, even though they are usually misleading at best. Of course I'm no exception. Here are three snippets of news on IronPython performance that have surfaced over the last week or so.

IronPython 2.0.1 and 2.6 Beta 1 compared to CPython and Jython (posted to Twitpic by felipez) on Mono revision 136556:


Using the pystones benchmark IronPython on Mono clocks in faster than CPython or Jython. Nice.

One particular bugbear of IronPython performance has been startup time. On 64bit Windows the startup time goes from being merely bad to positively ridiculous. This is because the .NET 64bit JIT is slow to do its job and IronPython generates a lot of code needing to be JITed at startup. A lot of work has gone into IronPython 2.6 to improve startup time (by reducing the amount of rule generation done on startup), and this blog entry Dave Fugate explains something they have done specifically to address startup perf on 64bit Windows - and shows off the results:
Allow me to elaborate on this perf gain...Dino made a change recently such that ipy.exe is now strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems. ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes. At least part of the perf gain here comes from the fact that my simple Hello World program is most definitely not consuming anywhere near 4 gigs of memory, and overall memory consumption goes up for 64-bit processes => remember the size of pointers gets doubled. Just checked and the physical memory working set of ipy.exe was 31K compared to 44K under ipy64.exe for the Hello World program. This ~30% difference in memory consumption helps explain why we get better perf under ipy.exe.
The next blog entry is in Chinese and compares performance of a few operations in IronPython and C#. As you might expect C# is faster in general, but interestingly IronPython is actually faster than C# for reflection.

Python Support in Visual Studio

Many .NET developers (all too many alas) are not willing (or not allowed) to use any language that isn't integrated into Visual Studio. As IronPython is a dynamically typed language it is much harder to build full support into Visual Studio - although there have been two attempts so far (the SDK for Visual Studio 2005 and IronPython Studio for Visual Studio 2008).

In this blog entry Dave Fugate (IronPython tester and infrastructure guy for Microsoft) explains the current state of VS support for Python and as Visual Studio 2010 approaches he looks to the future...
I think I speak for everyone on the IronPython Team when I say we’d love to see IronPython support in Visual Studio by default without the need for any language service addition. The thing is these types of decisions are made at a much higher level than us and are heavily influenced by business needs. What I’m getting at here is if enough people provided feedback via the proper channels that:
  • The next version of VS is great, but it’d be better if it supported Python development
  • You don’t currently use VS but you would if it had Python support
  • Ahem…you’d be willing to pay for IronPython support in VS
  • Etc
then the next version of VS could very well have Python support built into it. What are the proper channels for feedback you ask? The VS 2010 feedback page would be a great start.
If you're looking for an IDE for working with IronPython the best option currently is probably SharpDevelop, which has great IronPython integration.

Monday, June 22, 2009

__clrtype__ Metaclasses: Positional Attribute Parameters

Harry Pierson (the IronPython Program Manager for Microsoft) has been exploring and explaining the new __clrtype__ feature coming in IronPython 2.6 (or already available if you are using the beta).

When we last left him Harry had been creating Python classes with simple .NET attributes applied to members. In this post he delves further and applies attributes that take parameters:
The basic infrastructure for custom attributes in IronPython is in place, but it’s woefully limited. Specifically, it only works for custom attributes that don’t have parameters. Of course, most of the custom attributes that you’d really want to use require additional parameters, both the positional or named variety. Since positional parameters are easier, let’s start with them.

Positional parameters get passed to the custom attribute’s constructor. As we saw in the previous post, you need a CustomAttributeBuilder to attach a custom attribute to an attribute target (like a class). Previously, I just needed to know the attribute type since I was hard coding the positional parameters. But now, I need to know both the attribute type as well as the desired positional parameters. I could have built a custom Python class to track this information, but it made much more sense just to use CustomAttributeBuilder instances. I built a utility function make_cab to construct the CustomAttributeBuilder instances.

A Good Mix 12: Upcoming Presentations, XML Namespaces, ArcGIS and the Hungarian Phrasebook

Yet another selection of blog entries and articles relating to IronPython from the last few weeks.
The Coding Geekette (Sarah Dutkiewicz) is a regular at .NET and Python conferences speaking, amongst other things, about IronPython. In this blog entry she lists her forthcoming talks:
There is also quite a bit of IronPython content at the forthcoming EuroPython 2009 in Birmingam (28th June to 4th July): an IronPython tutorial, ArcGIS and IronPython talk, Introduction to IronPython talk, Ironclad talk and a general Python VM panel discussion.
A Japanese blog demonstrating how to load and save XML from IronPython - using the .NET APIs and working with namespaces. In this case he is iterating through a directory of XHTML files and adding valid namespace declarations.
A short snippet of code showing how to work with .NET APIs that take delegates from IronPython.
Another short 'reminder' blog entry from Simon Taylor, who seems to be having fun with IronPython. String formatting is Python 101 - but is not something you will automatically understand when coming from C#. Interestingly the new string formatting in Python 3.0 (which I'm not really a fan of) is lifted straight from C#.
Silverlight (the browser plugin) is great fun to program with IronPython, but has the disadvantage of it not being possible to compile assemblies instead of deploying source code. One developer at least is keen to change this and has started the "Hungarian Phrasebook" project to create an IronPython pre-compiler for Silverlight.

This is a topic I've looked into a bit, and discussed on the IronPython mailing list, and came to the conclusion it's not easily possible. (There is no cross-compiling support in Reflection.Emit and the APIs used by the Python compiler Pyc will only save to disk which doesn't work in Silverlight.) There is no code in the project yet but I hope it works.
The perrygeo blogger would love to use IronPython with ArcGIS, but discovers that with IronPython 2.0 he has to explicitly call through the interfaces for most of the APIs, making the code painfully verbose.
And then he tries IronPython 2.6 instead of IronPython 2.0 and finds it works as expected. Joy and delight ensues...
Works perfectly now. So IronPython 2.6 promises to be a viable option for extending ArcGIS. My enthusiasm has been renewed.
Nice to finish on a happy note.

Tuesday, June 16, 2009

__clrtype__ Metaclasses: Simple Custom Attributes

One of the exciting new features in IronPython 2.6 is the addition of the __clrtype__ metaclass. This allows you to specify and customize the .NET type that backs your Python classes.

This is important because by default new Python classes aren't also .NET classes. This is for various reasons: Python classes are mutable, .NET classes can't be garbage collected and so on. This causes one of the biggest gaps in the IronPython integration; using .NET attributes requires them to be applied to a real .NET class. There are other features, like some kinds of data binding, also a real .NET class.

There are techniques to overcome this, but they're clunky at best. In IronPython in Action I demostrate runtime generation, compilation and subclassing of C# classes as one technique.

At last the __clrtype__ metaclass provides a better way built into IronPython, but it is a pretty low-level feature requiring a lot of work to build on top of it. Harry Pierson, the IronPython program manager, has been showing how to use __clrtype__ to fill some of these use cases. In his first series of articles Harry demonstrated databinding with Silverlight. Now he has started to tackle custom attributes:
Over the course of the next three blog posts, I’m going to build out a mechanism for specifying custom attributes on the CLR type we’re generating via __clrtype__. All the various Builder classes in System.Reflection.Emit support a SetCustomAttribute method that works basically the same way. There are two overloads – the one I’m going to use takes a single CustomAttributeBuilder as a parameter.

For this first post, I’m going to focus on the basic custom attribute infrastructure, so we’re going to use the extremely simple ObsoleteAttribute. While you can pass some arguments to the constructor, for this first post I’m going to use the parameterless constructor. To keep things less confusing, I’m going back to the original version of the Product class, before I introduced CLR fields and properties. The one change I’m making is that I’m adding a list of attributes I want to add to the class.

Embedding IronPython as a scripting language

Mark Bloodworth, Microsoft Architect Evangelist, shows how to use IronPython to add scripting to a .NET application.
A great way of extending an application is to allow users to write their own scripts. Fortunately, with the Dynamic Language Runtime it is fairly simple to provide scripting in your application. Let’s look at how to do it with a simple Windows Forms application and IronPython.

...

It’s simple to add powerful scripting support to your applications, while maintaining control over the scripting runtime means that you can restrict what any user entered code can do. I chose to show this example in IronPython, but the principles for doing this with Ironruby are identical (of course you’ll need a reference to IronRuby.) In fact, you could offer users the choice of languages.

Sunday, June 14, 2009

IronRuby 1.0 (soon), Inside IronRuby and Professional IronRuby

IronPython 1.0, a complete implementation of Python for the .NET framework, was released in September 2006. The first IronPython 2.0 release (Alpha 1) came in April 2007. IronPython 2.0 was built on the new Dynamic Language Runtime (DLR) which was a framework for implementing dynamic languages in general, which had been abstracted out of the IronPython 1.0 release.

Along with the new IronPython 2.0 project IronRuby was announced. IronRuby was an implementation of Ruby for .NET, led by John Lam who had previously been involved in the RubyCLR project. It has been a long road for IronRuby, with the latest release version 0.5.
Following their tradition of conference driven releases (panic-driven-development?) IronRuby 1.0 will be released at the coming OSCON 2009 conference:
IronRuby is 1.0! Come and see how IronRuby is used in .NET programs, how well it performs, and how conformant it is. IronRuby is an Open Source implementation of the Ruby programming language, built on top of Microsoft’s Open Source Dynamic Language Runtime. OSCON has an important place in the history of IronRuby, and it is only appropriate that we launch IronRuby 1.0 at OSCON 2009.
Jimmy Schementi is a member of the Microsoft dynamic languages team. In this 43 minutes channel 9 video he discusses the IronRuby project:
Jimmy Schementi is a Program Manager (and developer) on the IronRuby team. IronRuby is an Open Source implementation of the Ruby programming language for .NET, heavily relying on Microsoft's Dynamic Language Runtime. IronRuby is Ruby, but implemented on top of the DLR (which of course provides the capability for dynamic languages to interact with the BCL and CLR).

You've learned about the details of the DLR here on 9, which provides dynamic runtime support for .NET. IronRuby targets compatibility with the 1.8.x branch of Ruby modulo continuations. IronRuby is an implementation of Ruby version 1.8.6.

Here, Jimmy explains the thinking behind the IronRuby project. Why are we doing this, anyway? When/Why would Ruby developers use IronRuby? What's the current status of the project? What's the future hold for IronRuby? Tune in and learn about the past, present and future of IronRuby.
Early reviews of IronRuby in Action (for Manning Publications by Ivan Porto Carrero) are good, but it isn't the only IronRuby book in progress. Hot on the heels of Pro IronPython being released is Professional IronRuby, by Wrox and due out any day.
Professional IronRuby provides a complete guided tour through IronRuby, demonstrating why Ruby is important, what IronRuby can add to your .NET development arsenal, and how you can take advantage of Ruby while utilizing existing infrastructures. Building on your existing .NET knowledge, the authors will walk you through Ruby’s syntax and structure and the ways you can use IronRuby for .NET projects. Learn how to apply IronRuby to ASP.NET and Silverlight and decide where to develop your components, with straight-forward guidance on when and why to use IronRuby instead of C#, and vice versa.
Meanwhile Ivan continues to work IronRuby in Action (the companion book to IronPython in Action). He has just posted a sample ASP.NET MVC example using IronRuby to his blog that will be one of the examples in the book.

Saturday, June 13, 2009

A Good Mix 11: A Rules Engine, Embedding, SharePoint and NWSGI

Another selection of blog entries and articles relating to IronPython from the last few weeks.
A blog entry from Dave Fugate (IronPython testing and infrastructure guy) on an exception message that shouldn't be visible. Looks like it is actually a bug in Vista, but as it was triggered by IronPython it gets a mention here:
IronPython most definitely should not be able to spawn an error message box that's visible when Vista is locked at the username/password screen. Quite annoying yet very interesting at the same time...
Another blog entry from Mark Bloodworth (a Microsoft Architect evangelist) on using IronPython. It demonstrates writing classes in C# and using them from IronPython. The entry is short because this is something that IronPython makes trivially easy:
It’s really simple to use a .NET class in IronPython. The first thing to remember is that you’ll need to add a reference (just like you would in .NET). To do that you use the AddReference method of the clr module. In the case of an assembly you’ve written, IronPython needs to be able to find it, which means it needs to be in sys.path. It turns out that you can add the path to your assembly by using the append method of sys.path.
This project is actually not new at all, I just hadn't heard of it. It's nice to discover people using IronPython in ways I wasn't aware of. This project is by Glen Cooper and he describes it here:
This library provides the ability to automate various
SharePoint activities through easy to read and modify Python
scripts.

The core library is located in the sp module. The scripts
module contains a number of scripts for performing specific
activities such as backing up sites.
A good use case for embedding IronPython in a .NET application is to use it as a rules engine for evaluating rules stored as text which can be modified or added to without requiring recompilation of the application. This is exactly what Nathan of the Crippeoblade blog has been up to:
In my last post I talked about creating a rules engine to generate a scouts evaluation of a player. Having played with IronPython for a few hours this evening I’ve managed to introduce a dynamic script to represent the rule engine. This means I can replace the rules engine or for that matter any one else can without having to re-compile the code. It’s suddenly dawned on me how this exciting technology can make a game extensible. With .NET 4 introducing the dynamic keyword plus other functionality for dynamic languages it’s going to make it even easier.

Performance wise it actually seemed pretty fast. This was one concern I had because of the greater work at runtime required. Objects aren’t statically typed so the runtime engine has to do the typing at runtime. Just starting to learn python and I must say I’m loving it so far. I’ve done nothing complex just followed a few tutorials and coded up a small script to test out ironpython running within c#. So how did I manage that.
It seems like only a few days since the release of NWSGI 1.1 Preview 2 was announced, but it seems there was a problem with configuration on 32bit machines: "NWSGI 1.1 Preview 3 is a refresh of Preview 2 that fixes issues with configuration on 32-bit platforms. The release can only be used for xcopy deployments."

NWSGI is an implementation of the WSGI specification (Web Server Gateway Interface) for IronPython. It is implemented as an ASP.NET HttpHandler and is supported on the IIS 6 / 7 webservers (or any ASP.NET capable server). NWSGI allows the integration of Python applications like Trac and Django with existing ASP.NET facilities such as caching, sessions, and user management.
Embedding IronPython in C# is so easy everyone is at it. Here is another example; including executing code and fetching the result and populating a DataTable and manipulating it from IronPython.

A New Book on IronPython: Pro IronPython

IronPython in Action may have been the first book (in English) on IronPython but it is no longer the only one. Pro IronPython, by Alan Harris for Apress, is now available.
IronPython represents a unique direction for developers interested in working with dynamic languages within the .NET Framework. Whether you’re looking to develop applications from scratch or add functionality and maintainability to an existing application, IronPython opens many doors while providing a high–speed, high–performance language that integrates tightly with other .NET languages.
  • Learn to create applications using the benefits of a dynamically typed language.
  • Discover how to leverage the power of IronPython to improve existing applications.
  • Explore interacting with other .NET languages by invoking the common language runtime.
What you’ll learn
  • Write IronPython console and forms applications.
  • Integrate IronPython scripts into existing applications to increase their functionality.
  • Implement complex data patterns and interact with databases.
  • Use the common language runtime to take advantage of .NET’s existing framework within IronPython scripts.
  • Understand how IronPython can be brought in to solve a variety of programming tasks through extensive exercises and recipes.
  • Avoid the common pitfalls of working with a dynamically typed language.
Who is this book for?
This book is designed for .NET developers interested in expanding their IronPython skills and learning how to make use of them to improve their daily programming practices. It will introduce core concepts of IronPython programming using a .NET–centric approach. Additionally, it will speak to Python developers looking to expand into their skills into the .NET world. Experience with a .NET language is expected. Previous Python experience is not necessary.

About the Author
Alan Harris is a web and application developer living in Arlington, VA. He has worked at more than a few organizations using .NET to create enterprise solutions since the glory days of version 1.1, and can still browse to some of the oldest ones. Aside from working at his desk, he spends most of his time studying Krav Maga and writing music.
Before the book was published Alan and I exchanged a few emails, discussing duck-typing and the different audiences for IronPython in Action and Pro IronPython. In the process I ended up getting quoted in the intro to his book:
"Many developers take issue with this and find the approach too loose, too error-prone. I was speaking to Pythonista and author Michael Foord about the matter; I mentioned the argument, “What if it looks like a duck, quacks like a duck, but is really a dragon impersonating a duck? You don’t want a dragon in your pond.” He replied, “if you code dragons, you’ve got no one to blame but yourself if they get in your pond.” I informed him that “the only difference between my IronPython dragons and my C# ones is my C# ones have ‘Hello my name is’ nametags.” So it goes."

I will be interested to see what you think of "Pro IronPython". I've had the luxury of reading both your book and mine, and I think you'll agree we speak to very different audiences. Apress wanted a book easy enough that someone with zero programming experience could pick it up and run, being pretty well versed by the end (which pretty much speaks to the entire Pro line I think, with a few exceptions). Your book covers some terrific stuff (the PowerShell parts I found particularly interesting) but a lot would be beyond the target audience of mine. I think, however, that they are rather complimentary books.

Thursday, June 11, 2009

Mono can now compile IronPython 2.0

If you follow this blog, or the state of IronPython on Mono, you will know that the version of IronPython included in Mono (from the FePy project) is quite out of date. This is because (for various reasons) Mono has been unable to compile IronPython 2.0 from source which has prevented a new FePy release.

This causes a problem with running the IronPython in Action examples from Mono and I wrote a blog entry about how to work around this:
The intention is that MultiDoc, along with as many examples from the book as possible, run on both Mono and the .NET framework; IronPython isn't just for Windows but can also be used on Linux and Mac OS X or anywhere that Mono will run.

Some readers have reported that MultiDoc crashes on exit when run with Mono. The root cause of this is the old version of IronPython 2 that ships with Mono.

...

This is reason enough to look at using a more recent version of IronPython 2. Even though IronPython can't be compiled with Mono you can still use the up to date Windows binaries (which is part of the point of Mono - binary compatibility). To use the latest version of IronPython (2.0.1) you'll need Mono 2.4 or more recent...
However there is good news on this front. Ankit Jain recently posted the following to the Mono development email list:
Current xbuild status:

It can handle solutions (.sln) now, thanks to Jonathan Chambers, with C#, VB.net projects. Handles embedded resources, satellite assemblies, project references etc.

Eg. Paint.Net 3 ( builds completely with it now, IronPython (2.0.1) builds, IronPython svn (builds with compile time errors) etc.

Only .net 2.0 projects are supported currently though. I will start adding support for newer versions very soon, also ASP.NET, Silverlight etc projects.

This is part of the mono 2.4.2 release and is a *big* improvement over xbuild in the last release. Would be really helpful to get feedback and bug reports on this :)
In his status update Seo Sanghyeon (FePy maintainer) did report that IronPython 2.6 trunk could be built with Mono, so it looks like a recent checkin has broken Mono compatibility - temporarily I'm sure. However, the news that Mono can now compile IronPython 2 is great and hopefully means that a FePy update will follow on shortly.

Why Choose IronPython over C#?

Matthew Harelick just asked (on the Python.NET mailing list of all places) why he should consider using IronPython:
My background is primarily UNIX. I have been programming in C, TCL, Perl, and Python in UNIX and Linux for a long time.

I recently started working in Visual Studio and C#.

Visual Studio and C# make everything very easy. Python was nice when you didn’t have the convenience of Visual Studio and intellisense with a nice debugger.

In the windows world I see no major reason not to use C#.

Why would I want to use IronPython?
A lot of C# developers feel the same way, why should they consider another language? Here is my answer:
Both Python and C# are 'general purpose' programming langugages suited to a wide range of problem domains. Choice of programming language is therefore usually a matter of aesthetics, what you are used to, personal workflow, issues within a team and so on rather than a matter of which is more appropriate to the job. Obviously there are exceptions where one language is obviously more appropriate or obviously inappropriate but these are the exception rather than the rule.

Place where you should obviously use IronPython:
  • For embedding as a user scripting language / plugin mechanism or are doing runtime code generation
Place where you should obviously use C#:
  • You have already implemented in a dynamic language, profiled and optimised, and need faster performance than the dynamic language is capable of
Other than that the choice is yours!

Here are a few reasons why I / some people prefer IronPython:
  • The interactive environment is an invaluable tool for exploration
  • No need to create a whole 'object-oriented-application' for simple tasks where it is not needed
  • Without a compile phase and with duck typing / dynamic typing IronPython makes it dramatically easier to do test driven development or even normal unit testing
  • Python has many language capabilities missing from C# which make it a flexible and concise language. These include:
    • Duck typing and protocols (no need for explicit interfaces)
    • Heterogeneous containers (no need for generics)
    • Pain free introspection (no need for the complexity inherent in System.Reflection)
    • Metaprogramming including good old eval, type creation at runtime, decorators and descriptors
    • Late binding and runtime type dispatch
    • 'Little features' like tuple unpacking, returning multiple values, everything is an object (including primitives, functions, classes and modules)
There are things that C# has that Python doesn't (compile time checking, method overloading, access to .NET attributes), but choose whichever you prefer.
I've written about this subject before (and at a bit more length) in Dynamic Languages and Architecture.

Other reasons I didn't think about the time:
  • If you are starting out Python is much easier to learn than C#.
  • As a concise and expressive language it is faster to prototype solutions in Python and faster to turn those prototypes into full applications!
  • Writing portable, cross-platform code. Compatibility with CPython is a great thing.
  • Availability of open-source libraries. There are orders of magnitude more open source libraries for Python than there are for C# despite C# being used more than Python in commercial settings.
  • Python is the 'standard' language in various problem domains (GIS and animation scripting, Linux system administration and certain types of scientific programming for example).

Tuesday, June 09, 2009

A Good Mix 10: WPF, .NET Introspection, the Solver Foundation, Resolver One and Cobra

Another selection on a wide range of topics from the last few weeks.
Resolver One is an IronPython spreadsheet system and is the largest IronPython codebase in production. Normally a new release would be big news but we've already covered the Python console which is the biggest new feature in version 1.5. Other big new features include CSV import / export and a goto line dialog for the code editor. You can read a full list of all the improvements in the changelog. Now that 1.5 is out we're working hard on features for version 1.6. Our latest blog entry has a sneak preview of one of the coming attractions.
For Python methods you can use the inspect module to get information about methods / functions; like what arguments they take and so on.

Methods on .NET types don't have the attributes used by inspect (although methods of Python objects defined in IronPython work fine). We can get around this by using .NET reflection to introspect them them.

Reflection is normally done with classes from the System.Reflection namespace. We don't have to use these classes directly, but get them indirectly.

This IronPython Cookbook entry is an example of getting information about the OpenStandardOutput method of the System.Console class. We can then get the return type (something not available in Python) and the names of all the parameters.
A Japanese blog entry showing example IronPython code for a movie player capable of playing H264 encoded movies using the Windows Presentation Foundation MediaElement class (in 34 lines of code).
Microsoft Solver Foundation is a solver framework. The webpage is so full of buzzwords that its hard to get a clear definition of what it does. This looks like the closest:
Solver Foundation uses a declarative programming model, consisting of simple compatible elements that are solved by application of solvers, meta-heuristics, search techniques, and combinatorial optimization mechanisms to accelerate the solution finding process. Building a model in Solver Foundation is as simple as specifying the decisions to be made, constraints to be respected, the goals to be used to evaluate candidate proposals (solutions) and the data to be processed by the model (historical or projected parameters).
This kind of approach is very useful for working with data in spreadsheets. Suresh has posted some example IronPython code (an Optima Petro Sample) which works standalone or can be used with Resolver One.
Another Japanese blog entry from the blog that brought us the video player example. This example code shows using the Windows Presentation Foundation GUI library to create a simple window with Menu and shortcut keys. The menu is populated from a small snippet of XAML.
Cobra is a Python inspired programming language for the .NET framework. We've often covered news and updates on Cobra here on the IronPython-URLs blog. This article in the June edition of MSDN magazine, by well known .NET developer Ted Neward, is the first installment of a column on Cobra:
In the first installment of this column, I discussed the importance of understanding more than one programming language, and in particular, more than one kind of programming language; just knowing C# and/or Visual Basic isn't enough to stand out against the mob anymore. The more tools in your toolbox, the better the carpenter you become. (Up to a point, anyway—'tis the poor carpenter who owns every tool ever made and yet still doesn't know how to use any of them.)

In this installment, I'll examine a language that's not too far removed from the object-oriented languages you're familiar with, but has a few new features that will not only offer some new ideas, but potentially kick-start some new ways of thinking about your current tool set.

Allow me to introduce you to Cobra, a descendant of Python that, among other things, offers a combined dynamic and statically typed programming model, built-in unit test facilities, scripting capabilities, and some design-by-contract declarations.


DateSelector and Excel COM Automation Examples

Greg Bray has been using IronPython since entering (and winning) a round of the Resolver Systems spreadsheet competition. Since then he has had fun experimenting with IronPython has posted a couple of fairly complex example programs to his blog.
I have been playing around with IronPython recently while creating spreadsheets in Resolver One. So far I have been having a lot of fun, but I haven't really been doing anything that would be useful in a work setting. The main reason for this is because most of the spreadsheet work that I do revolves around pivot tables and Auto Filter, which are immensely helpful for visually analyzing data. I thought I might try and use Excel's COM Automation to add Pivot Charts and Auto Filter to any system with IronPython, and here is the code that I have come up with so far.

...

The code should be pretty straight forward. The Reload() method is helpful for reloading the whole module when testing from a console. The Run() method shows the steps to load a new spreadsheet. The ExcelManager static class is the core of the logic and provides an entry point for interacting with the spreadsheet.

There is not a lot of debuging code, so if something goes wrong it is just going to throw an exception, but this should be enough to help get things started. I did fix some funky problems with importing DateTime, where they kept getting converted into integers. Should work fine now, but anything other than Datetime, numerical types or strings will probably not get imported correctly.
Another quick IronPython snipet that shows how to use the Windows.Form.MonthCalendar control to create a simple date selector.

...

Works well for selecting singe dates, and could be modified to support selecting a date range if desired. I prefer having a Start Date and End Date, and selecting each separately.

Monday, June 08, 2009

Microsoft and Open Source

Microsoft has an antagonistic history with open source to say the least. With posturing on Linux and patents still being in the very recent past the Microsoft of today still has a schizophrenic mindset on the topic. This is hardly surprising; Microsoft has bet the shop on desktop software and its major products have open source competitors (Windows -> Linux, Office -> Open Office, Visual Studio -> SharpDevelop, Eclipse and a thousand others).

My experience of dealing with Microsoft and Microsoft employees has been very different, and very positive. IronPython is fully open source and was the first project to be released under Microsoft's OSI approved Ms-PL (Microsoft Public License). The members of the dynamic languages team that I have had dealings with understand open source and are committed to it; hardly surprising given that the project was established by Jim Hugunin a longstanding member of the Python community.

Despite this the IronPython development process is shackled with some lawyer imposed restrictions. Community members can't contribute to the project, IronPython developers can't look at the source code of Python itself and IronPython can't submit code changes or fixes back to Python or its standard library. It is only recently that we have had public commit messages on checkins to the public repository and that the Python standard library has been included with IronPython. The team still aren't able to modify the standard library for better compatibility with IronPython though; neither do they publish the internal tests they use on IronPython. These restrictions slow down and hamper IronPython development but it is still a fantastic project for those of us using Python on the .NET framework.

These restrictions come from Microsoft paranoia. In the past they have purchased code from other companies and when it turned out that the code wasn't legally owned by the people selling it they naturally sued Microsoft rather than the company that sold it to them. This has cost them many millions of dollars, so perhaps a measure of paranoia is understandable.

These issues are all understood by the dynamic languages team, and they are an important part of pushing forwards Microsoft's involvement in open source. Harry Pierson (IronPython Program Manager) has just done a presentation on this very topic in the Presentation Idol competition, and has written up his presentation as a blog entry:
Microsoft and Open Source are often portrayed as enemies. But in DevDiv, we have several high profile Open Source projects. I work on IronPython, which has been Open Source for over four years. More recently, the ASP.NET and Extensibility Framework teams have decided to release some projects as Open Source.

I believe we should have more Open Source projects at Microsoft. But more importantly, I feel that we need to go beyond the textbook definition of Open Source. Our Open Source projects are typically closed to external contributions. But for the ecosystem at large, Open Source isn’t just about the availability and distribution terms of the source code. It also implies a collaborative development model - parties working together across organizational boundaries, contributing directly to projects in question.

The thing I would most like to change about Microsoft would be to let members of our ecosystem contribute code to our Open Source projects.

iLove Sharepoint Reads IronPython in Action and Announces IronSharepoint

Christian Glessner is head of development at Data One and a Sharepoint expert. Even before IronPython in Action came out he was experimenting with integrating IronPython with Sharepoint and he has now enthusiastically reviewed the book with this in mind:
IronPython In Action covers all you need to get started with IronPython for a .NET or Python developer. It is written coherently without needless ballast, well suited to the philosophy of the language itself. My favorite chapters are “Silverlight: IronPython in the browser”, “Agile testing where dynamic typing shines” and “Embedding the IronPython engine”. The book has inspired me to found the CodePlex project IronSharePoint (coming soon) showing how you can develop SharePoint apps with IronPython. I’m convinced that in the near future dynamic languages will get more attention again, just think of the “dynamic” keyword in C# 4.0. Absolutely worth keeping an eye on it!

Sunday, June 07, 2009

A Good Mix 9: Cookbook recipes, articles and examples

Another selection of articles on IronPython from the last few weeks.
Saveen Reedy has a problem finding IronPython. More to the point he has an issue reliably finding the installed location when using both 32bit and 64bit versions of Windows (which have different standard install locations).
A short blog entry demonstrating how IronPython integrates with the .NET framework by creating a simple GUI with Windows Forms and the interactive interpreter. The steps are virtually the same as I use when demoing IronPython to a .NET crowd.
This one is a bit meta, but still useful. It's a recipe I put on the IronPython cookbook and shows a 'slightly-different-from-the-usual' way to integrate C# with IronPython. It shows how you can use C# to programmatically create Python modules for use from IronPython.
Scott Hanselman has been playing with IronPython and .NET 4.0. He had some odd errors caused by old versions of the IronPython assemblies floating around. This blog entry of his is on using the Fusion Log Viewer to track down the problem.
Here's an example of how a tiny bit of digging saved me hours of confusion recently when I hit an unusual edge case. I was doing a build of sample that was showing C# interop-ing with IronPython, but I was using a daily build of .NET 4 and a random build of IronPython.

I made a mistake and had some really old DLLs floating around that I shouldn't have had. My symptom was a FileNotFoundException for the file "System.Dynamic.dll." I KNEW it was in the GAC (Global Assembly Cache) and I could SEE it as a reference DLL in my directory. Can't find the file? Dude, it's right there!
Yet another person discovers how easy it is to use IronPython to interact with .NET assemblies and classes. He also likes IronPython in Action which is nice.
A Codeplex project that has been around for a while but I hadn't seen before. Someone has ported the ZedGraph charting library examples from C# to IronPython.

IronPython at Resolver Systems

These videos are from presentations my colleagues Jonathan Tartley and Giles Thomas did for Skills Matter in London. Inexplicably they are filed under Erlang on the Skills Matter website.
Jonathan Hartley, a developer at Resolver Systems talks about IronPython, and how it is used at Resolver Systems.

Resolver Systems's first product, Resolver One, is a desktop and web-accessible spreadsheet aimed primarily at the financial services market. It is written entirely in IronPython, and directly exposes end-users to Python, both as expressions in cell formulae, and as an embedded scripting language which provides programmatic access to spreadsheet content.

Resolver One launched in Spring of 2008, by which time the team had grown to fourteen people, and the codebase to 40k lines of product and 140k lines of tests. Here is an article by Jonathan about use of IronPython at Resolver Systems.
At the same event my boss, Giles Thomas, spoke about founding a startup:
Giles Thomas shares the story of founding Resolver Systems and answers questions about the company. Resolver Systems was founded in 2005 to produce a next generation spreadsheet. The founders, Giles Thomas, Robert Smithson and Patrick Kemmis, had all struggled with the challenges of running multi-million or multi-billion dollar businesses through poorly debugged spreadsheets. Their solution - Resolver One - seamlessly integrates a powerful and flexible programming language (IronPython) and a traditional spreadsheet environment. Resolver One is used by companies in the financial, oil exploration and pharmaceutical industries and in academia.

Saturday, June 06, 2009

IronPython Is it a dead parrot or does it fly?

"IronPython Is it a dead parrot or does it fly?" is the question asked by Mike James in an article in VSJ. It covers Python the language, .NET interop, and an example of using the WPF (Windows Presentation Foundation) GUI library from IronPython.
Python is one of the increasingly trendy dynamic languages and it is now available under the .NET umbrella. IronPython is an open source version of the language developed by Guido van Rossum in 1990. Python has a great many users and they are all passionate about the language and mostly about Monty Python as well. Yes, there are lots of Pythonesque (as in the well-known TV series) references in the Python world, but it is a very serious language as well! It currently runs on most platforms, and IronPython extends this range to .NET and Silverlight.

Why bother?
Python may be free and it may be a high quality language but so is C#. Why bother with a strangely named language that you probably haven’t heard very much about? One good reason is that it is an interactive object-oriented language that has managed to take the good ideas from many other languages and meld them together into something workable. If you have looked at early versions of IronPython, now is a good time to take another look because version 2.0 has just been released and this is based on the new Dynamic Language Runtime (DLR) which all of the .NET dynamic languages should be using quite soon. The DLR is an extension to the CLR designed to make it easy to implement dynamic languages. The best argument for Python, however, is to use it – so let’s get started.

SharpDevelop: Exploring and Debugging IronPython Code

Matt Ward is the maintainer of the IronPython support in SharpDevelop, a .NET IDE for Windows. His latest entry takes us through the IronPython debugger built into SharpDevelop. This was built using the techniques explored by Harry Pierson in writing his IronPython debugger. Crucial to debugging IronPython is "Just My Code" support (so you don't have to wade through the Dynamic Language Runtime internals when you want to step through Python code) - and this is the name of the feature in SharpDevelop.
Ensure that the Just My Code feature is checked and that the Step over code without symbols is not checked. If the Step over code without symbols option is selected then stepping will not work properly and lines of code will be skipped over.

There are two ways to debug your code. You can use the Python menu or modify the project options. We will look at both of these alternatives. First open your IronPython project into SharpDevelop. Open your main file and make sure it is the active text editor window. Set a breakpoint somewhere in your code. Then from the Python menu select Run...
Darell Hawley is a Microsoft C# MVP with an interest in IronPython. With the new IronPython support in SharpDevelop 3.1 he's been giving it a spin and blogged his initial impressions:
  • SharpDevelop is an open source IDE for the .NET platform. Is it new? Hardly. Based on the history of news releases from their website, It’s been around since December of 2000. Considering that the .NET platform was publicly announced only 6 months earlier, SharpDevelop seems only that much more mature.
  • If you’re comfortable with the basics of Visual Studio, SharpDevelop should feel like home to you. In fact, the best way to describe SharpDevelop is “Visual Studio without a lot of stuff I don’t want and a few third-party items I do”.
  • SharpDevelop uses NUnit instead of MSTest. That’s right. No third party plugins to make your IDE work with NUnit. It simply works.
  • It’s time for me to confess. It’s all about IronPython. The reason I started investigating SharpDevelop is because of my frustration with Visual Studio’s lack of support for the language. Specifically, I want Intellisense when I write IronPython. To be sure, you only get Intellisense for “non-DLR code”, but surprisingly that doesn’t seem to be as much of a handicap as you might think.
  • Speaking of first class citizens, SharpDevelop comes stock with C#, Visual Basic, Boo (I can hear Jay Wren cheering now), IronPython and F# (now a number of SRT folks are cheering).
  • If you’re frightened of the consequences that may come from changing your development environment, don’t be. You can open one of your existing Visual Studio solutions with SharpDevelop and start coding. Switching back is as simple as opening up your now modified project/solution in Visual Studio.
  • Friday, June 05, 2009

    .NET Module Testing with IronPython

    One of the areas where dynamic languages particularly shine is testing. There is a whole chapter of IronPython in Action on the subject (chapter 7 which is free to download and is a great introduction to unittest and testing topics for both Python and IronPython).

    The .NET world is starting to realise this, and a new MSDN article by Dr. James McCaffrey explores both 'ad-hoc' testing with the interactive interpreter and writing your own test harness in IronPython for automated testing of .NET classes and libraries. (Personally I think he would have found it much easier to use unittest, but as you can see from the article even writing a custom test harness can be done in very little code with Python.)
    The Python scripting language has features that make it an excellent choice for performing several types of software testing. There are several implementations of Python available including CPython, the most common implementation on machines running UNIX-like operating systems, and IronPython, an implementation released in late 2006 that targets the Microsoft .NET Framework. In this month's column I'll demonstrate how to use IronPython to test .NET-based modules from both the Python command line and in lightweight Python scripts.

    Methodist: Make .NET Reflector come alive with IronPython

    No, not a reference to a once dynamic spiritual movement that is now largely part of the institutionalised church, but a new plugin for .NET Reflector.

    Reflector is a tool for exploring and disassembling .NET libraries. From binary assemblies it will show you all the classes and their members including the relationships between them. It will also disassemble them back into C# or VB.NET source code; invaluable for understanding the behavior of objects but a nightmare if you feel the need to protect your source.

    Ben Hall, UK MVP, C# expert and dynamic languages enthusiast has created a plugin for Reflector which makes it even more useful. Part of the power of dynamic languages is how easy they make exploration from the interactive environment. Ben has brought this to Reflector by embedding an IronPython interpreter (REPL). Whilst you are looking at the available methods and their arguments and return values you can actually instantiate classes and use them from the interpreter.

    As well as being a useful tool the source code is another good example of embedding IronPython into a .NET application (plus how to write a Reflector plugin of course). In this article Ben explains how to use the tool and how it works under the hood.
    It is great to be able to inspect the contents of an assembly with .NET Reflector, but to really understand the behaviour of code, it is nice to be able to call methods and see the results immediately within .NET Reflector. Now you can, thanks to the magic of IronPython and the DLR. Ben builds a REPL add-in for .NET Reflector and makes a great tool even more useful.

    Thursday, June 04, 2009

    Running KirbyBase in IronPython

    KirbyBase has a small but warm place in my heart as the first database I ever used in an application. It is a pure-Python single module database that stores its data in plain-text delimited files and has a Pythonic query syntax. Sure you don't want to run a high volume website with it but it is fun to use and experiment with.

    Krishna Bhargav has been using it from IronPython and has written up a blog entry on how to get it working with IronPython 2.6:
    As I was looking for embedded database systems, I came across this pure python database called KirbyBase. So I decided that I would make it run on IronPython. So this post describes on how to make KirbyBase run on IronPython and using ipy.exe. Note that I am not looking at integrating this database into C# application yet. [may be in the future post]
    Using Python libraries from C# is an interesting topic (covered briefly in IronPython in Action of course) which I don't think enough people have experimented with. The need is to create a statically-typed wrapper layer which the C# can use and handles calling into Python and returning values.

    In particular I'd like to see a C# wrapper using Ironclad, so that Numpy can be used from C#. There don't seem to be any open source libraries for .NET that are anything like as comprehensive.

    There is also Curt Hagenlocher's Coils project which (if completed) could automatically generate the wrapper classes from Python class definitions.

    An Australian, a Frenchman and an American read IronPython in Action

    In the last couple of weeks three new reviews of IronPython in Action have gone online, and by reviewers from three different continents.

    The first is from Tarn Barford who is an Australian .NET programmer with an interest in IronPython. He has blogged and presented about IronPython, and now he has reviewed IronPython in Action:
    IronPython in Action is a fantastic resource for anyone learning IronPython and for anyone wondering what this dynamic language IronPython is all about and whether they should learn it. It feels nicely balanced for both .NET users looking to learn about IronPython, and for Python users looking to learn about IronPython on .NET.

    I prefer software books that have plenty of discussion and can be read from start to finish otherwise I end up skipping through chapters I never go back too. I found this book well written and fun to read with interesting insight all the way through. There is enough about the python language and .NET to get you through the book, and rather than being a reference book it instead provides information on how to learn more.
    Matt Brucher is a French Python programmer with an interest in scientific computing. His review (in English) describes the contents of the book which I think he liked:
    IronPython is the first dynamic language developed for the .Net platform. At first, .Net didn’t support this kind of language. This is something that keeps on coming back throughout the book: you have to use some additional tricks to unleash the power of .Net dynamic and static languages.

    As a conclusion, those who need a dynamic language (to script an application) can go for IronPython, the first dynamic language for the .Net framework, compatible with the language Python 2.5, and in that case, go for this book that will help you for anything.
    The final review of this trio is by the token American Scott Koon, who is a well known .NET developer under his nom-de-blog Lazycoder:
    I’ve always wanted to use Python more but it’s difficult because the .NET Framework is such a walled garden in terms of interoperability with other programming languages. Mostly I use it to write little one off scripts when I want to move a bunch of files around or parse some text. I was really excited when Manning asked to to review IronPython in Action because I wanted to dive a little deeper into Python and possibly use it in some web applications. “IronPython in Action” makes it easy to get started using IronPython right away.

    Chapter 7 discusses agile testing and unit testing using IronPython. I almost dropped the book in amazement. Unit testing is almost never mentioned in any language book and is relegated to a niche or advanced topic. Find a book about any other .NET language that mentions unit testing that doesn’t have the word “testing” in the title. This alone sets the quality of this book far above other language books I have read. It’s not just enough, in my opinion, to discuss the syntax of the language. You have to teach the reader how to use the language in your everyday work.

    My overall feeling about this book is that it’s a great book. The authors use the same humor and dry wit that Python is known for to great effect. Making the digestion of a very different language easier. I’m sure that as I continue to experiment with IronPython that I’ll keep this book close at hand.

    My favourite quote from all these reviews is from Scott's: "If anything exposes the cruel, unnecessary complexity of .NET, it’s got to be a Winforms app." Actually I quite like Windows Forms, but it's still a good quote.

    Wednesday, June 03, 2009

    Davy's IronPython Editor 00.01.71 Released

    In a recent entry I listed some of the editors and IDEs you can use with IronPython, but I missed one off the list: Davy's IronPython Editor.

    This is an IDE for IronPython written in IronPython and is the creation of Davy Mitchell. It comes in installable and mobile versions and the latest release is version 00.01.71.
    Nearly 2 months on since the last release and the project has changed a lot and whilst not a massive update, I seriously recommend this upgrade. Thanks to the IronPython mailing list for support, suggestions and inspiration. Like any other project out there, I am desperate for feedback :-) Also if you have any new ideas for the future, let me know.

    DIE has had about 400 downloads since launch. With blossoming interest in IronPython, (partly, I suspect, due to IronPython in Action) hopefully it will hit the 1000 mark soon! So pop along and download.

    Here's the detail in what has changed in 00.01.70:
    • Mobile Version which stores options in same dir.
    • Installed version stores in User Profile. (Existing Settings files don't transfer over - sorry).
    • 'Find in Files' feature added.
    • Much much Improved Capture of output from running Python scripts.
    • Click on error output now opens file and goes to line.
    • Resources - MSDN links area now low bandwith versions, Python links and Powershell launch menu.
    • Added CheckBox and Listbox control to gen_GUI.
    • Syntax Box -Exposed new property to get Caret Screen position.
    • Autocomplete option added - default to OFF. Experimental parsing for strings, lists and dictionaries.
    • Bug fixes and performance updates.

    A Good Mix 8: Python 101, Regular Expressions, Silverlight, IronRuby and More

    The Coding Geekette is a Python and .NET developer who has spoken on IronPython at many developer conferences including PyCon. Her next adventure is teaching .NET developers Python in Cleveland:
    What: "Python 101 for the .NET Developer" with Sarah Dutkiewicz, Cleveland C#/VB.NET SIG

    When: Tuesday, June 23, 6:30-8:30pm

    Where: Beacon Place Conference Center, Beacon Place Office Building, 6055 Rockside Woods Blvd, Lower Level, Independence, OH 44131
    This blog entry (non-English) shows two interactive sessions using the System.Text.RegularExpressions.Regex class; performing the same task from both IronPython (2.6 beta) and IronRuby (0.4). The interactive interpreter is a great environment for experimenting, and the sessions ably demonstrate this.

    Of course you could also achieve the same thing with the Python re module.

    This is true of many things in IronPython, file and path handling or threading being two more examples; you have the choice of whether to do things the Python way or the .NET way. Whether you use the Python standard library or .NET framework libraries depends on which you are more familiar with, whether you need the code to be portable across implementations or whether one of the alternatives more closely matches what you need to achieve.
    IronPython has been designed to make it easy to embed in .NET applications. With code evaluated and executed at runtime it opens up all sorts of possibilities for user scripting of applications, storing rules as text that can be created and modified at runtime and so on. Hosting IronPython in Silverlight is slightly different from desktop .NET applications. Although the hosting API is the same there is some initial configuration that needs to be done.

    I've updated my article on the topic to include the configuration needed for IronPython code to import from other Python files contained in the xap file, plus adding references to the standard .NET / Silverlight assemblies.
    An O'Reilly Radar article. James Turner interviews Eric Schuman about how Microsoft tests user experiences on its websites. Notable for this quote:
    JT: Microsoft has done a lot of work providing dynamic language support through projects through IronRuby and IronPython. Do those technologies find any traction internally?

    ES: Oh, yeah, actually. I think it depends a lot on what group you're in. Like in the research teams, they tend to be used more than the product teams that I've been on. But there's definitely -- we're all geeks, you know? You get geeks and you get neat technologies and the geeks will try and use them. So I know that Iron Python, I know quite a few people who've experimented with it for everything from build tools to little data analysis tools.
    IronRuby in Action is a book being written for Manning Publications by Ivan Porto Carrero. About half the book is complete and available through the Manning Early Access Program. Jan Van Ryswyck has posted a review of the book so far...
    Moonlight 2, the Mono port of the Silverlight 2 browser plugin for Linux, is making great progress. Preview 3 is out now and can run my IronPython web-IDE example. You can now script the browser with Python on Windows, Mac OS X and Linux.

    Tuesday, June 02, 2009

    NWSGI Release and Django on IronPython

    Jeff Hardy certainly keeps himself busy. First of all he has done a new release of NWSGI:
    NWSGI 1.1 Preview 2 is exactly the same as Preview 1, except linked against IronPython 2.6 Beta 1. NWSGI is an implementation of the WSGI specification (Web Server Gateway Interface) for IronPython. It is implemented as an ASP.NET HttpHandler and is supported on the IIS 6 / 7 webservers (or any ASP.NET capable server). NWSGI allows the integration of Python applications like Trac and Django with existing ASP.NET facilities such as caching, sessions, and user management.
    NWSGI isn't quite sufficient to get Django running with IronPython. To remedy this Jeff has a project hosted on bitbucket (Mercurial version control repository) with patches to support Django on IronPython.
    On a casual glance the patches look pretty unobtrusive although I don't know how many of the Django tests pass on IronPython. It would be an important milestone to finally have Django working fully on IronPython.

    How to install IronPython 2 with Mono on Ubuntu

    IronPython has been included with Mono for quite some time. The versions included are the last releases of the FePy project (IronPython Community Edition), which are a stable version of IronPython 1 and an alpha version of IronPython 2 - both very old.

    In the FePy status update Seo Sanghyeon (FePy maintainer) explains the difficulty of compiling the latest stable version of IronPython with Mono. It is easier to compile IronPython 2.6 (the up and coming version), so hopefully we will see a new release of FePy - along with an update in Mono - when this is released later this year.

    In the meantime the latest binary versions of IronPython released by Microsoft work with recent versions of Mono (although they need a terminal with a dark background). In this post Ali Afashar explains exactly what you need to do to get a cooperating version of IronPython and Mono working on Ubuntu.
    This is just an instructional post with the hope that it might help others in the future.

    I spent a long time trying to get IronPython2 running on Mono. Now IronPython1 ships with Ubuntu, so
    apt-get install ironpython
    , if that's all that you want. Ironically, I don't really know the difference between IronPython1 and IronPython2, but "2 has got to be better than 1", right?

    The good news is that its very possible, but you will have to step out of your comfort zones.

    You will need: Mono 2.4 (sources) and IronPython 2.0.1 (binary)