Very good summary. However I am surprised your forgot one reason that appears very important to me as to why a Python programmer would like to use IP. Simply because it increases his audience for his product and therefore extend the user base and if you build a company on your product this means your market gets bigger as well.
What worries me a little is that when I follow the IP ML it seems that most .NET developers see IP as a simple scripting language but not much more and as you say Python programmers don't even seem to be interested overall.
So we may end up with two communities that will share a lot but won't talk to each other. This would be sad for both parts because there is much to learn from both sides.
The Python community is already fragmented. There is the scientific crowd who are doing marvelous things with scientific visualization and interfacing Python to dozens of useful libraries. There is the ZOPE/Plone crowd who seem totally inscrutable to those of use who have never been tempted to dive into those behemoths. There is the cool web framework of the month who chase after RubyonRails as if it were the holy grail of programming. The Tk GUI crowd don't talk much to the WxWindows crowd who don't talk much to the GTK crowd. All 3 GUIs are used on the same set of platforms. The past is littered with deadend stuff like PalmPython, PocketPC Python, Jython and Zaurus distros. PYS60 is still relatively current but who knows?
Python is already fragmented into dozens of camps. IronPython merely adds another option to the mix.
Great review ! But it seems you forget the goal of pypy, no ?
Pypy should provide an unique implementation of python in python. With this, and translators, this would be possible to target any plateforms (c, java, .net ...). When it will be really mature/usefull, a python developper will release his python program in .net by using pypy (and not IP), in java by using pypy (and not jython) ... it's the goal of Pypy to deliver an unique implementation in python , no ?!?
"IronPython is more important for bringing .NET programmers to Python than it is for bringing Python programmers to .NET."
I am one of those .NET developers who only tried Python because of IronPython. The funny part is I have yet to find a need to actually use IronPython over CPython!
Built-in security model with AppDomains (CPython can't do this out of the box, although Brett Cannon is working on a model and Zope does something interesting)
Could you explain the above line a bit? Where can I learn more about it, it sounds intersting.
You hit the nail on the head saying that IronPython is a simpler sell to the corporate environment. Especially because it now comes out of Microsoft. I show .NET developers all the time some of the syntactical sugar of using the python language. What I'm really looking into now, though, is using IronPython with XAML for rich UIs -- though I want to check out XUL. I'm finding Python in general is a much easier sell to tech management than Ruby, too.
Thinking positively, we have Python in many flavours and we should respect all the efforts made until now. Finally, people has the liberty and intelligence to choose the best option that fits their necessities and dreams.
I'm very glad IronPython exists. At work, we have to use .NET (for political reasons), and IronPython will help me be much more productive - I'm already experienced in CPython.
As far as GUI's go, tk has some neat ideas and promotes a different approach than the traditional Windows VB/VCL/WinForm approach - for example, in many cases it is better to create the form dynamically, and sizers really help.
You can do sizers in WinForms, but none are supplied, most .NET programmers don't have a clue, so you really have to roll your own.
--Tony
UNIX fragmented. If not for Linux, UNIX would probably be dead. Microsoft is perpetuating similar
fragmentation via (funding for) Iron Python. Lets all
resist Iron Python's 'embrace-and-extend' tricks.
We've been through this chicanery before ...
Commenting by HaloScan
