Hi,
I'm new in using Python. I would like to develop Windows GUI Application using Python. After some research, I found that I have 2 options:-
May I know which one is better for Windows Application development? Which option has more features (e.g. database support, etc)?
Other than the .NET support, is there any big difference between IronPython and Python? Which one is a better choice for me?
Thank you.
Patrick.L
First, there are lots more than 2 options (python has more GUI libraries than you can shake a stick at), but let's go on your premise for a minute. "Better" being subjective begs the question: "what do you want to learn?"
If the goal is Windows GUI Applications development, than I'd go with .Net. .Net is well respected, there is lots of work for .Net programmers, and it's windows centric nature (yeah I know there's Mono but still) means you aren't trying to think about details of three+ sets of user expectations.
If the goal is to learn widely used Python libraries and techniques, I'd go with PyQt (and recently did). It's cross-platform, well respected, and has a large community. But you lose the chance to learn the .Net platform as part of this project.
I don't think you can loose either way if your goal is to learn. If your goal is to get something done, think about the long-term plans for the project and where its going over the long run. Do you want something that's well integrated into the Windows user-interface, and uses standard widgets? Do you want something that can easily be adapted to other platforms in the future?
I haven't used IronPython with .NET, but I have written a lot of PyQt code. From my experience, PyQt is a great library. It is a very well executed bindings to Qt, which is a very well known and widely used library.
Since it's standard Python you're writing, you can enjoy all the Python standard library which gives you a ton of capabilities, in addition to several useful Qt modules imported with PyQt. Writing PyQt code is productive, and the GUIs come out pretty and responsive. And you can't ignore the portability benefit: with just the tiniest modifications, if any, you can just run these programs on Linux and they will just work.
PyQt is a great library, but .NET is the best way to go for Windows. That is because you can use any GUI controls that C# would be able to use in Python. Furthermore, in addition to WinForms, IronPython can be used to create WPF applications, which look good.
The main difference is the features, and PyQt has more cross-platform features, and .NET definitely has the edge in Windows.
I faced the same issue and have, with misgivings, decided to go with IronPython/C#/.Net. I liked Qt but got cold feet when it was sold to Nokia because I just wasn't sure Nokia's goals in owning Qt were consistent with my needs for a windows UI. That said, Nokia has made some positive moves by combining separate platform licenses into a single license and dropping GPL licensing in favor or LGPL.
Technically, Qt is well designed but relies heavily on hard to debug C# macros. I'm not sure why. The best thing about Qt is that it is open source. If you need to, you can fix it. I don't have direct experience with PyQt but it has been around for quite a while.
.Net is .Net and as usual with Microsoft, a moving target. You will sacrifice speed for ease of coding. The IronPython group seems good but I'm not sure if Microsoft's commitment is there. Visual Studio support isn't there yet although the plans sound good. After all, MS only really cares if they own everything, which is not the case for Python. What I really expect is MS will create a dynamic version of C#, interpreter and all, and tell all the Python programmers that it is better and supported and well integrated with .Net. They will then through their considerable weight behind crushing Python like they've done to Java.
Good luck. It's a big decision.
Per my play with both PyQt (as interface to Qt) and IronPython (as an interface to WinForms) the bag is mixed.
Both are basically "bindings" for underlying platforms. PyQt is practically "autogenerated" from Qt's API and slightly more "mature" as a wrapper because of significant use on Linux.
IronPython goes a little deeper and seems to "rebox" system objects with small unfilled gaps between cPython and .Net libs (gzip, zip, subprocess etc).
In both cases, you need to look through Python into the toolkit and say to yourself if you like the toolkit. All python is doing is repackaging the toolkit's API to the objects. Again, forget about Python aspect. Look at the underlying toolkit API and think to yourself if you can live with that.
I personally find the C++ nature of Qt's API too un-pythonic to be happy with it. C# and Python are so alike that if you remove curlies and type declaration from C# you would not know if it's C# or Python. As a result, for a Python programmer, C#-based .Net API, code and examples as provided in MSDN and elsewhere are instantly applicable with very minor tweaks.
In the end, a more correct comparison would be between PyQt (Qt bindings for cPython) and Win32py (Windows ABI bindings for cPython). IronPython is almost a reinvention of same language on a different platform, with all the problems (lacking functionality) that comes with that.