python .net ironpython cpython python.net

IronPython contra Python.NET



cpython (10)

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

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

¿Cuáles son las compensaciones entre ambas soluciones?

  1. Ironpython es como C # a su vez se basa en bibliotecas estáticas preconstruidas, 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, lo que a su vez se traduce en la necesidad de escribir todo.

  3. Ironpython es más rápido que C # en ciertas áreas, pero no más rápido que Cpython, sin embargo, puedes vincular Ironpython a cualquier idioma para problemas futuros, pero nuevamente puedes hacer lo mismo con Cpython.

Un lenguaje divertido, simple y poderoso sin importar lo que elijas!

En cuanto a 2016.

En mi compañía utilizamos IronPython, pero no estábamos satisfechos con las prestaciones (la mayoría del uso de memoria, el recolector de basura era demasiado lento), así que decidimos cambiar a Python estándar e integrarlo con .Net usando Zeroce-s ICE.

Iron Python es básicamente Python 2.7 con soporte de .NET integrado, probablemente nunca sea compatible con Python 3. Pierde en bibliotecas de C y Python, sin embargo, en el lado de giro tiene acceso a .net y puede ampliarse con C #. Entonces, si usas C #, entonces Iron Python es una bonificación.

IronPython es ".NET-native", por lo que será preferible si desea integrar completamente su código de Python con .NET hasta el final; Python.NET funciona con Classic Python, por lo que te permite mantener el código de tu Python lejos de .NET. (Tenga en cuenta que con este código puede usar extensiones escritas para CPython a partir de su código IronPython, por lo que ya no es una condición discriminatoria).

IronPython viene de Microsoft, así que iría con mis instintos y usaría eso primero, ya que debes asumir que funcionará mejor con otras tecnologías de MSFT.

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

de IronPython 3 "Builds of IronPython 3 aún no se proporcionan".

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 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 CPython GUI 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.

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 puedes compilar Python con el módulo NET como una aplicación no administrada.

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 Global Interpreter Lock (GIL). Si bien IronPython no tiene las limitaciones del GIL, CPython sí lo hace, por lo que parece que para aquellas aplicaciones en las que el GIL es un cuello de botella, por ejemplo, en ciertos escenarios multinúcleo, IronPython tiene una ventaja sobre Python.NET.

De la documentación de Python.NET:

Nota importante para los embedders: Python no es de subproceso libre 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. Mucha más información sobre esto está disponible en la documentación de la API de Python C en el www.python.org web www.python.org .

Al integrar Python en una aplicación administrada, debe administrar el 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 espacio de nombres Python.Runtime , el código de llamada debe haber adquirido el bloqueo de intérprete global de Python llamando al método PythonEngine.AcquireLock . La única excepción a esta regla es el método PythonEngine.Initialize , 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 PythonEngine.ReleaseLock correspondiente para liberar el GIL y permitir que otros subprocesos usen Python.

Los métodos AcquireLock y ReleaseLock son envoltorios delgados sobre las funciones PyGILState_Ensure y PyGILState_Release no administradas de la API de Python, y la documentación para esas API se aplica a las versiones administradas.

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

Si desea basar principalmente su código en .NET Framework, le recomiendo IronPython vs Python.NET. IronPython es bastante nativo de .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 de Python estándar.

Existen diferencias notables al usar IronPython, pero la mayoría son bastante sutiles. Python.NET utiliza el tiempo de ejecución CPython estándar, 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 de Python estándar no funcionan tan bien en IronPython debido a su implementación.