Why use IronPython?

7 October 2008

I just posted this on the Joel on Software discussion board, in answer to someone’s question about using IronPython for their new company.  Hopefully it will be of interest here.

We’ve been using IronPython for three years now with a lot of success.The great thing about it is that it allows you to benefit from Python’s syntax while getting most of the advantages of .NET:

  • All of the .NET libraries are available.
  • UIs look nice.  I’ve never seen a pure traditional Python application that looked good, no matter how advanced its functionality.
  • We use a bunch of third-party components – for example, Syncfusion’s Essential Grid – without any problems.
  • Reasonably decent multithreading using the .NET libraries – CPython, the normal Python implementation, has the problem of the Global Interpreter Lock, an implementation choice that makes multithreading dodgy at best.
  • We can build our GUI in Visual Studio, and then generate C# classes for each dialog, and then subclass them from IronPython to add behaviour.  (We never need to look at the generated code.)
  • When things go wrong, the CLR debugger works well enough – it’s not perfect, but we’ve never lost a significant amount of time for want of anything better.

Of course, it’s not perfect.  Problems versus using C#:

  • It’s slower, especially in terms of startup time.  They are fixing this, but it’s a problem in the current release.  This hasn’t bitten us yet – all of the non-startup-related performance issues we’ve had have been due to suboptimal algorithms rather than language speed.  However, it you’re writing something that’s very performance-intensive, you may want to look elsewhere.
  • No LINQ yet.
  • If you’re considering IP then you presumably already know this, but dynamic languages have no compile-time to perform sanity checks on your codebase, so problems can come up at runtime.  We write all of our code test-first and so we aren’t impacted by that.  However, if you’re not writing a solid amount of test code (and if you’re not, you should :-) then you might want to use a statically-typed language.

Problems versus using CPython:

  • No cross-platform.  Linux or Mac support is one of our more frequently-requested enhancements, and it will be a lot of work to add.  The reason for this is that many third-party .NET components – for example, the Synfusion grid – are not “pure” .NET; they drop into win32 for certain operations, I assume for performance reasons.  This means that if you use them, your application won’t run on non-Windows .NET platforms.
  • No use of CPython’s C extensions, like numpy (a numerical functions library).  This has hit us pretty hard, so we’re working on an open-source library to interface between C extensions and IronPython – however, it’s still a work in progress.

Hope this was of some help.

5 thoughts on “Why use IronPython?

  1. Chris Vickerson

    what about .Net Attributes? You must have had to interface using System.Attribute… I’ve been playing with IronPython, but this [missing] feature could prevent it from going very far.

  2. Pingback: Dew Drop - November 10, 2008 | Alvin Ashcraft's Morning Dew

  3. giles Post author

    Chris – you’re right, the lack of attributes could be a problem – however, it slipped my mind because it’s not something that’s really impacted us much. The only place I can think of straight away is in our P/Invoke code, where we had to drop down into C#.

    I guess serialization is another area where we might have had problems, but we’re using pickle instead.

  4. Jon Harrop

    You may also like to look at F#. Performance, support, libraries, data structures, algorithms and reliability (without extensive testing) are all much better.

    Also, threading is either for concurrency (latency) or for parallelism (throughput). CPython already handles concurrency and if you want parallelism (= performance) you shouldn’t be using any kind of Python anyway.

  5. Michael Foord


    F# is interesting – but we’ve already built a product on IronPython. We’re not about to jump ship. :-)

    We use threading for both – to keep the GUI thread active whilst spreadsheets are calculating and to allow multiple documents to recalculate concurrently. IronPython is great for concurrency using .NET threads.

Comments are closed.