IronPython vs Python.NET

Si bien estoy de acuerdo con las respuestas dadas por Reed Copsey y Alex Martelli, me gustaría señalar una diferencia más: el Bloqueo Global del Intérprete (GIL). Si bien IronPython no tiene las limitaciones del GIL, CPython sí, por lo que parece que para aquellas aplicaciones donde el GIL es un cuello de botella, digamos en ciertos escenarios multinúcleo, IronPython tiene una ventaja sobre Python.NET.

De la Python.NET documentación:

Nota Importante para embedders: Python no es free-threaded y utiliza un bloqueo de intérprete a permitir aplicaciones multihilo para interactúa de forma segura con Python interprete. Mucha más información acerca de esto está disponible en Python C Documentación de la API sobre el www.python.org Sitio web.

Al incrustar Python en un sistema gestionado aplicación, usted tiene que gestionar el GIL de la misma manera que lo haría al incrustar Python en un C o C++ aplicación.

Antes de interactuar con cualquiera de los objetos o API proporcionados por el Python.Runtime espacio de nombres, código de llamada debe haber adquirido el Python global bloqueo del intérprete llamando al PythonEngine.AcquireLock método. El la única excepción a esta regla es la PythonEngine.Initialize método, que se puede llamar al inicio sin habiendo adquirido el GIL.

Cuando termine de usar las API de Python, el código administrado debe llamar a un PythonEngine.ReleaseLock para liberar el GIL y permitir que otros hilos para utilizar Python.

El AcquireLock y ReleaseLock los métodos son envoltorios finos sobre no gestionada PyGILState_Ensure y PyGILState_Release funciones de la Python API, y la documentación para esas API se aplican a la versiones.

Otro problema es el soporte IDE. CPython probablemente tiene mejor soporte IDE en la actualidad que IronPython - por lo que esto puede ser un factor en la elección de uno sobre el otro.

La mayoría de las bibliotecas científicas y numéricas de Python que dependen de CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) están trabajando sobre todo bajo CPython, por lo que en ese caso su mejor apuesta es pythonnet (otros nombres - Python.NET y Python para. NET). Lo mismo es cierto para los enlaces GUI de CPython como wxWidgets, PyQt / PySide, GTK, Kivy, etc., aunque tanto pythonnet como IronPython pueden usar WPF y WinForms.

Y finalmente IronPython aún no es totalmente compatible con Python 3.

IronPython es "nativo de. NET" so por lo que será preferible si desea integrar completamente su código Python con. NET hasta el final; Python.NET funciona con Python clásico, por lo que le permite mantener la "longitud del brazo" de su código Python lejos de.NET propiamente. (Tenga en cuenta que con este código puede usar extensiones escritas para CPython desde su código IronPython, por lo que ya no es una condición discriminatoria).

IronPython viene de Microsoft, así que iría con mi instinto y utilizar que uno primero, ya que tienes que asumir que jugará mejor con otras tecnologías MSFT.

Como para 2016.

En mi empresa utilizamos IronPython, pero no estábamos satisfechos con las actuaciones (sobre todo el uso de memoria - garbage collector era demasiado lento) así que decidimos cambiar a Python estándar e integrarlo con.Net utilizando Zeroce-s ICE.

IronPython, actualmente, no es compatible con Python 3.6 (solo 2.7)

Desde IronPython 3 "Las construcciones de IronPython 3 aún no se proporcionan."

1. Ironpython es como C# a su vez se basa en estático prediseñadas bibliotecas, mientras que a diferencia de C# es un lenguaje dinámico.

2. Cpython es como C++ como Ironpython es un lenguaje dinámico y tiene acceso a bibliotecas dinámicas que a su vez se traduce en ser obligado a escribir todo.

3. Ironpython es más rápido que C # en ciertas áreas, pero no más rápido que Cpython, sin embargo, puede vincular Ironpython a cualquier lenguaje, por lo tanto, sobre los problemas que vienen, pero de nuevo se puede hacer lo mismo con Cpython.

Un lenguaje divertido, simple y poderoso independientemente de lo que elija!

Iron Python es básicamente Python 2.7 con soporte.net integrado probablemente nunca soportará Python 3. Pierde en las bibliotecas de C y Python, sin embargo, en el lado de twist tiene acceso a.net y se puede extender con C#. Así que si ya usas C#, Iron Python es una ventaja.

Prefiero principalmente Python para.NET, porque IronPython se compila como código administrado, que se puede descompilar fácilmente (lo que más odio), pero con py2exe o pyinstaller puede compilar Python con NET module como una aplicación no administrada.