Why Use IronPython
My boss has a blog! Even better, he's actually writing entries occasionally. He recently answered a question on the Joel on Software discussion board about whether or not a new company should consider using IronPython:
He cites the advantages of IronPython as:
Another interesting post is his description of how we're transitioning development at Resolver Systems away from being a single team into two. This is due both to growth in the development team and the need for us to do development work for some of our larger customers. The entry includes an example Resolver One spreadsheet that uses an evolutionary algorithm to do scheduling to spread developers across the two teams over time:
The evolutionary algorithm is mainly implemented in IronPython user code in the spreadsheet, using the spreadsheet interface for data entry and displaying the results.
He cites the advantages of IronPython as:
- 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.
Another interesting post is his description of how we're transitioning development at Resolver Systems away from being a single team into two. This is due both to growth in the development team and the need for us to do development work for some of our larger customers. The entry includes an example Resolver One spreadsheet that uses an evolutionary algorithm to do scheduling to spread developers across the two teams over time:
The evolutionary algorithm is mainly implemented in IronPython user code in the spreadsheet, using the spreadsheet interface for data entry and displaying the results.
Some of your points are not accurate. I think I like nitpicking.
ReplyDeleteThe multiprocessing (formely pyprocessing) module offers decent multi-code concurrency with an almost identical API and no almost no disadvantage (a bit higher memory usage on Windows because of no copy-on-write).
No proper threading, you are right.
PyQt4 looks great and wxPython looks decent. Both work and integrate on all relevant platforms (except for wx in kde). What good looking GUI toolkit does .NET have?
You can build GUIs in QtDesigner or wxGlade and get python code that you never need to look at.
There are pretty good debuggers for python and their need is not as high as in statically typed languages.
You're probably better off commenting on Gile's blog, but... to nitpick a few of your points...
ReplyDelete* multiprocessing doesn't offer in process concurrency and so is not suitable for use cases that require the sharing of data-structures (the serialization IO imposes a big penalty and is not always possible for arbitrary objects)
* There are several good cross-platform GUI toolkits for Windows. None of them are as native looking on Windows as Windows Forms though.
* As for debuggers - you said "their need is not as high as in statically typed languages" - he is using IronPython... sometimes you do need a debuger though...
@fuzzyman - thanks for the plug :-)
ReplyDelete@sin - I think you may have read the article as a "here's why you should use IronPython rather than Python" argument. It was actually more "here's why you should use Python rather than C#, or, God help you, Visual Basic."
So...
* I agree that there's good multiprocessing support in Python - if you're working in a problem domain where you can use multithreading instead of multithreading, then IP's better threads aren't an advantage. However, IP does have the edge over Python if you need MT.
* WinForms is the big UI toolkit for .NET. I've not seen any pure-Python apps that look as "professional" to me as WinForms. I appreciate how subjective an assessment that is... Perhaps Fuzzyman's wording, "native-looking on Windows" is a more objective way of describing what I'm trying to say. However, I would assert (and I say this as someone who coded in Java/Swing for many years) that apps written using cross-platform GUI toolkits almost inevitably look less "right" (for some value of "right") to naive users than native apps do.
* You can indeed build GUIs in GUI designers in other platforms. Visual Studio is good, but I've no idea whether QtDesigner ot wxGlade are better. (I personally have a soft spot for X-Designer on Motif, which was the first app I worked on professionally :-) I mentioned VS because it's there and it works, meaning that the tool-chain for IP is as complete as it is for Python.
* Yes, there are good debuggers for Python - you'll note that I was saying that the CLR debugger is "good enough", not that it's better! Again, this was an obvservation on the toolchain.
HTH