Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
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?
If you want to mainly base your code on the .NET framework, I'd highly recommend IronPython vs Python.NET. IronPython is pretty much native .NET - so it just works great when integrating with other .NET langauges.
Python.NET is good if you want to just integrate one or two components from .NET into a standard python application.
There are notable differences when using IronPython - but most of them are fairly subtle. Python.NET uses the standard CPython runtime, so
this Wiki page
is a relevant discussion of the differences between the two implementations. The largest differences occur in the cost of exceptions - so some of the standard python libraries don't perform as well in IronPython due to their implementation.
–
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.
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.
IronPython is ".NET-native" -- so it will be preferable if you want to fully integrate your Python code with .NET all the way; Python.NET works with Classic Python, so it lets you keep your Python code's "arm's length" away from .NET proper. (Note that with
this code
you can actually use extensions written for CPython from your IronPython code, so that's not a discriminating condition any more).
–
–
Ironpython is like C# in turn it relies on static prebuilt libraries while unlike C# is a dynamic language.
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.
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!
Thanks for contributing an answer to Stack Overflow!
-
Please be sure to
answer the question
. Provide details and share your research!
But
avoid
…
-
Asking for help, clarification, or responding to other answers.
-
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our
tips on writing great answers
.
