IronPython vs. Python .NET

Question

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

A little research showed I have two choices:

• IronPython with .NET interface capability/support built-in
• Python with the Python .NET package

What are the trade-offs between both solutions?

Answer 1

While agreeing with the answers given by Reed Copsey and Alex Martelli, I'd like to point out one further difference - the Global Interpreter Lock (GIL). While IronPython doesn't have the limitations of the GIL, CPython does - so it would appear that for those applications where the GIL is a bottleneck, say in certain multicore scenarios, IronPython has an advantage over Python.NET.

From the Python.NET documentation:

Important Note for embedders: Python is not free-threaded and uses a global interpreter lock to allow multi-threaded applications to interact safely with the Python interpreter. Much more information about this is available in the Python C API documentation on the www.python.org Website.

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

Before interacting with any of the objects or APIs provided by the Python.Runtime namespace, calling code must have acquired the Python global interpreter lock by calling the PythonEngine.AcquireLock method. The only exception to this rule is the PythonEngine.Initialize method, which may be called at startup without having acquired the GIL.

When finished using Python APIs, managed code must call a corresponding PythonEngine.ReleaseLock to release the GIL and allow other threads to use Python.

The AcquireLock and ReleaseLock methods are thin wrappers over the unmanaged PyGILState_Ensure and PyGILState_Release functions from the Python API, and the documentation for those APIs applies to the managed versions.

Another issue is IDE support. CPython probably has better IDE support at present than IronPython - so this may be a factor in the choosing of one over the other.

Answer 2

IronPython, currently, doesn't support Python 3.6 (only 2.7)

from IronPython 3 "Builds of IronPython 3 are not yet provided."

Answer 3

Most of scientific and numerical Python libraries that rely on CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) are working mostly under CPython, so in that case your best bet is pythonnet (other names - Python.NET and Python for .NET). The same is true for 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 fully support Python 3 yet.

Answer 4

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

Answer 5

1. Ironpython is like C# in turn it relies on static prebuilt libraries while unlike C# is a dynamic language.

2. Cpython is like C++ like Ironpython is a dynamic language and has access to dynamic libraries which in turn translates to being forced to write everything.

3. Ironpython is faster than C# in certain areas but not faster than Cpython, however you can link Ironpython to any language thus over coming problems but then again you can do the same with Cpython.

A funny, simple and powerful language regardless what you choose!

Answer 6

As for 2016.

In my company we used IronPython, but we were not satisfied with performances (mostly memory use - garbage collector was too slow) so we decided to switch to standard Python and integrate it with .Net using Zeroce-s ICE.