IronPython vs Python.NET

Question

I want to access some .NET assemblies written in C # from Python code.

A little research showed that I have two options:

• IronPython with .NET interface support / support
• Python with Python.NET

What are the tradeoffs between both solutions?

Answer 1

If you want to mainly base your code on the .NET platform, I would highly recommend IronPython vs Python.NET. IronPython is pretty much native .NET - so it works great when integrated with other .NET langauges.

Python.NET is good if you just want to integrate one or two components from .NET into a standard python application.

There are noticeable differences when using IronPython, but most of them are pretty subtle. Python.NET uses the standard CPython runtime, so this Wiki page is a relevant discussion of the differences between the two implementations. The biggest differences occur in the cost of exceptions - which is why some of the standard python libraries do not work well in IronPython because of their implementation.

Answer 2

Agreeing with the answers made by Reed Copsi and Alex Martelli, I would like to point out another difference - Global Translator (GIL). While IronPython has no GIL limitations, CPython does this - it would seem that for applications where the GIL is a bottleneck, say in some multi-core scripts, IronPython has an advantage over Python.NET.

From the Python.NET documentation:

Important note for embedded applications: Python is not free and uses a global interpreter lock, allowing multi-threaded applications to communicate safely with the Python translator. Much more information about this is available in the Python C API at the www.python.org Web site.

When embedding Python in a managed application, you need to manage the GIL the same way you do when embedding Python in a C or C ++ application.

Before interacting with any of the objects or APIs provided by the Python.Runtime namespace, the call code had to get the global Python interpreter lock by calling PythonEngine.AcquireLock . the only exception to this rule is PythonEngine.Initialize , which can be called at startup without acquiring a GIL.

Once you have finished using the Python APIs, managed code must call the appropriate PythonEngine.ReleaseLock to issue the GIL and enable the use of other Python threads.

AcquireLock and ReleaseLock methods are subtle wrappers over the unmanaged PyGILState_Ensure and PyGILState_Release functions from the Python API and the documentation for these APIs applies to the managed version.

Another issue is IDE support. CPython currently has better IDE support than IronPython, so this can be a factor when choosing one of them.

Answer 3

Most Python scientific and number libraries that rely on the CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) work mainly under CPython, so pythonnet is the best choice (Python is another name .NET and Python for .NET). The same applies to CPython GUI bindings such as WxWidgets, PyQt / PySide, GTK, Kivy etc., although both pythonnet and IronPython can use WPF and WinForms.

And finally, IronPython does not yet support Python 3.

Answer 4

IronPython is ".NET-native" - ​​so it would be preferable if you want to fully integrate your Python code with .NET completely; Python.NET works with classic Python, so it saves Python "arm length" code from .NET itself. (Note that with this code you can really use extensions written for CPython from your IronPython code so that there is no more discriminatory condition).

Answer 5

IronPython comes from Microsoft, so I would go with my gut and be the first to use it, since you should assume that it will play better than other MSFT technologies.

Answer 6

As for 2016.

At my company, we used IronPython, but we weren’t satisfied with the performances (mainly using memory - the garbage collector was too slow), so we decided to switch to standard Python and integrate it with .Net using ICE Zeroce.

Answer 7

• Ironpython is similar to C #, in turn, it relies on static ready-made libraries, unlike C # - a dynamic language.

• Cpython is similar to C ++ since Ironpython is a dynamic language and has access to dynamic libraries, which in turn translates as having to write everything.

• Ironpython is faster than C # in certain areas, but not faster than Cpython, however you can associate Ironpython with any language, thus over future issues, but then you can do the same with Cpython.

Funny, simple and powerful language, no matter what you choose!

Answer 8

I mostly prefer Python for .NET because IronPython is compiled as managed code that can be easily decompiled (which I hate the most), but with py2exe or pyinstaller you can compile Python with the NET module as an unmanaged application.