IronPython frente a Python .NET

Quiero acceder a algunos ensamblados .NET escritos en C # desde el código Python.

Una pequeña investigación mostró que tengo dos opciones:

• IronPython con capacidad / soporte de interfaz .NET incorporado
• Python con el paquete Python .NET

¿Cuáles son las compensaciones entre ambas soluciones?

Si desea basar principalmente su código en el marco .NET, le recomiendo encarecidamente IronPython vs Python.NET. IronPython es prácticamente nativo .NET, por lo que funciona muy bien cuando se integra con otros lenguajes .NET.

Python.NET es bueno si solo desea integrar uno o dos componentes de .NET en una aplicación estándar de Python.

Existen diferencias notables cuando se usa IronPython, pero la mayoría de ellas son bastante sutiles. Python.NET usa el tiempo de ejecución estándar de CPython, por lo que esta página Wiki es una discusión relevante de las diferencias entre las dos implementaciones. Las mayores diferencias se producen en el costo de las excepciones, por lo que algunas de las bibliotecas estándar de Python no funcionan tan bien en IronPython debido a su implementación.

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 de intérprete global (GIL). Si bien IronPython no tiene las limitaciones de GIL, CPython las tiene, por lo que parece que para aquellas aplicaciones en las que GIL es un cuello de botella, digamos en ciertos escenarios multinúcleo, IronPython tiene una ventaja sobre Python.NET.

De la documentación de Python.NET:

Nota importante para los integradores: Python no tiene subprocesos libres y utiliza un bloqueo de intérprete global para permitir que las aplicaciones de subprocesos múltiples interactúen de forma segura con el intérprete de Python. Hay mucha más información disponible sobre esto en la documentación de la API de Python C en el www.python.orgsitio web.

Al incrustar Python en una aplicación administrada, debe administrar GIL de la misma manera que lo haría al incrustar Python en una aplicación C o C ++.

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

Cuando termine de usar las API de Python, el código administrado debe llamar a un correspondiente PythonEngine.ReleaseLockpara liberar GIL y permitir que otros subprocesos usen Python.

Los métodos AcquireLocky ReleaseLockson envoltorios finos sobre las funciones PyGILState_Ensurey no administradas PyGILState_Releasede la API de Python, y la documentación de esas API se aplica a las versiones administradas.

Otro problema es el soporte IDE. CPython probablemente tenga 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 Python científicas y numéricas que se basan en CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) funcionan principalmente bajo CPython, por lo que en ese caso su mejor opción es pythonnet (otros nombres: Python.NET y Python para .NET). Lo mismo es cierto para los enlaces de la 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", por lo que será preferible si desea integrar completamente su código Python con .NET; Python.NET funciona con Classic Python, por lo que le permite mantener su código Python "a distancia" de .NET propiamente dicho. (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 proviene de Microsoft, por lo que me guiaría por mis instintos y usaría ese primero, ya que debes asumir que funcionará mejor con otras tecnologías MSFT.

En cuanto a 2016.

En mi empresa usamos IronPython, pero no estábamos satisfechos con el rendimiento (principalmente el uso de memoria, el recolector de basura era demasiado lento), por lo que decidimos cambiar a Python estándar e integrarlo con .Net usando Zeroce-s ICE.

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

de IronPython 3 "Aún no se han proporcionado las versiones de IronPython 3".

1. Ironpython es como C #, a su vez, se basa en bibliotecas estáticas precompiladas, 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 forzado 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 idioma para superar los problemas que se avecinan, pero también puede hacer lo mismo con Cpython.

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

Iron Python es básicamente Python 2.7 con soporte .net integrado, probablemente nunca admitirá Python 3. Pierde las bibliotecas C y Python, sin embargo, en el lado del giro tiene acceso a .net y puede extenderse con C #. Entonces, si ya usa C #, Iron Python es una ventaja.

Principalmente prefiero 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 el módulo NET como una aplicación no administrada.