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.