ironpython和python-IronPython vs. Python .NET

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.