An added advantage is far faster runtimes thanks to bytecode-compilation (vs the default interpreted-code nature of Python in most circumstances).
You can write your code in Visual Studio on Windows or MonoDevelop on Linux. On Windows, it'll use the native Win32 controls, on Linux Mono will "draw" controls that look like the native ones without actually calling the native binaries - it allows for a huge compatibility boost and still manages to look 99% native (technically it's drawing the exact same native controls, but the drawings aren't perfect).
For the Windows platform, you could always get a copy of "Programming Windows" by Charles Petzold and call the Win32 API directly (not really recommended). For a native Windows look I suppose that Iron Python would be optimal as it has full access to the .NET Framework.The Mono project has made that effectively portable to the other supported platforms but you would end up having to immerse yourself in the .NET world view.
Otherwise I get the impression that most other GUI kits for Python have a "look" of their own and are thus going to stand out a bit on any given platform.
I will certainly be tracking this post to see what suggestions come up - thanks for posting the question.
If I remember correctly iron python ran on mono it just didn't have all of the .net bits. I remember at the python conference when it was introduced he actually showed how you could bring up clippy or a wizard programmatically from python talking directly to the operating system through its native apis.
Really the value came from the thread safe container/collections data types which are the foundation of high performance programming
If you have the luxury of using .NET, embedding IronPython is considerably easier, in my experience. A while back I was fooling around writing a game engine with python scripting support, and it was pretty slick to get going with.
Well the Mono project would make any Iron Python development portable to the Mac and Linux and would certainly meet your "Windows Forms" type requirement. Still, there are alternatives being suggested on this post that could meet the need by supplying just the GUI components.
IronPython does rock indeed. Being able to poke .NET libraries from a command line is really cool. I had an idea for a Windows IT administration app last year, so I spent some time poking around IronPython, .NET and Monad/PowerShell. I liked what I saw, I just wanted to try my hand at web development instead.
If you're using IronPython then you're probably just trying to embed a familiar scripting language into something, not trying to adopt the Python ecosystem.
Besides, while you lose out on Python's native ecosystem you gain access to all of .net's.
From reading the description, and from what little I know about IronPython...
IronPython is a re-implementation of Python in C# which allows it to play nice with .NET. This is similar to Jython which is a re-implementation of Python in Java that plays nice with the JVM.
This project on the other had is not a re-implementation at all, but aims to augment the existing CPython implementation with JIT APIs and is using CoreCLR for the JIT.
The author mentions that C# has a nice IDE (Visual Studio). I'd like to mention that a couple of OSS & Python enthusiasts at msft have produced one for Python as well (free/apache 2.0).
It supports both CPython and IronPython, along with intellisense, debugging, profiling, etc. : http://pytools.codeplex.com
Pywin32 to call native apis for GUIs sounds very, very painful. I had a few run-ins with pywin32 and COM automation, I don’t think I could bear the thought of developing a full UI with that sort of hacks. At that point, might as well go C# (or IronPython, if it’s still around) and enjoy the VS goodies.
Awesome. I'm really excited to be able to write DLL's in pure python for the CLR, and then hook them up to run in Windows as native-looking apps easily.
Now that there is a Python2.5 equivalent version, they can focus on getting performance out of IronPython, which is already really good:
It is still a thing, but it's open source now instead of maintained by Microsoft. There was a release that finally supports Python 3 in December last year.
I don't know how useful it is really, if you really want performance then you probably shouldn't choose Python to begin with, or you use the libraries which may not be compatible with IronPython. These days it barely takes me longer to build a simple script in C# than in Python either.
You are totally right, it had been a while since I had looked into this. I was confusing (blending together?) pyinex and IronPython. You are right, IronPython (and tons of other languages) all have access to the .Net libs, but pyinex is what I was thinking of. Apparently, though, it is not fully developed yet.
I'd say Nuitka or Cython are maybe the more common ones when talking about this. IronPython is/was interesting in that instead compiling to python bytecode or machine code it targetted the .NET CLR, and iirc I saw some kind of JIT going on when I was digging around (so some things ended up as machine code), but it's not really one of the usual "compiles python to machine code" implementations.
Neat, but that doesn't seem to be integrated into .NET like IronPython was (well, is, just not maintained it seems). Which is what the post I was responding to was talking about.
To my knowledge IronPython cannot easily call python extensions written in C/C++. So going with IronPython means using Microsoft's .NET libraries (or the mono clones) for many tasks, just as using JVM based languages means falling back to Java libraries as a replacement for those Python/Ruby libraries that haven't been reimplemented on top of the VM.
Python has a huge number of libraries and it keeps growing. I don't think the attempt to reimplement everything on top of .NET/Java is going to succeed. The people who maintain these libraries are not going to do it so where's the army of people who will take on such an incredibly boring task? I hope, one day, C/C++ libraries will be conveniently accessible from the VMs.
The only viable alternative would be to implement all Python libraries exclusively in Python. That's something that current maintainers of C/C++ extensions might consider doing. But Python would have to be much faster for this to work.
An added advantage is far faster runtimes thanks to bytecode-compilation (vs the default interpreted-code nature of Python in most circumstances).
You can write your code in Visual Studio on Windows or MonoDevelop on Linux. On Windows, it'll use the native Win32 controls, on Linux Mono will "draw" controls that look like the native ones without actually calling the native binaries - it allows for a huge compatibility boost and still manages to look 99% native (technically it's drawing the exact same native controls, but the drawings aren't perfect).
reply