2009-07-23 44 views
68

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

Un poco de investigación mostraron que tengo dos opciones:

¿Cuáles son las ventajas y desventajas entre ambas soluciones?

Respuesta

61

Si desea basar principalmente su código en .NET Framework, 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 this Wiki page 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.

+10

IronPython tiene ahora excepciones "ligeras" que son mucho más rápidas. Una prueba TryRaiseExcept de PyBench que se realizó 60 veces más lento, ahora es solo 1,6 veces más lenta. WithRaiseExcept sigue siendo lento, pero 4 veces más rápido que antes. Para la mayoría de las otras pruebas, IPy es realmente * más rápido *. [** Comparación de rendimiento de IronPython 2.7 vs CPython 2.7 **] (http://ironpython.codeplex.com/wikipage?title=IP27A1VsCPy27Perf) (complete [lista de puntos de referencia] (http://ironpython.codeplex.com/wikipage? title = IronPython% 20Performance)). – Athari

7

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 this code puede usar extensiones escritas para CPython a partir de su código IronPython, por lo que ya no es una condición discriminatoria).

7

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

+0

lo dudo porque no forma parte de vs20xx – user3800527

26

Aunque estoy de acuerdo con las respuestas de Reed Copsey y Alex Martelli, me gustaría señalar una diferencia más: la 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 Python.NET:

Nota Importante para embebedores: Python no es de subprocesamiento libre y utiliza un bloqueo global intérprete para permitir aplicaciones de subprocesos múltiples para interactúan de forma segura con el intérprete de Python . Mucha más información acerca de esto está disponible en la documentación de la API C de Python en el sitio web www.python.org.

Cuando la incrustación de Python en un aplicación administrada, usted tiene que manejar el GIL exactamente de la misma manera que lo haría al incrustar Python en una C o C++ aplicación.

antes de interactuar con cualquiera de los objetos o API proporcionadas por el Python.Runtime espacio de nombre, código de llamada deben haber adquirido el bloqueo mundial intérprete de Python llamando al método PythonEngine.AcquireLock. La excepción única a esta regla es el método PythonEngine.Initialize, que se puede llamar al inicio sin haber adquirido el GIL.

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

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

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.

+4

El complemento PyDev Eclipse admite CPython, IronPython y Jython. –

+3

@Knut: Correcto, pero esa no era la situación cuando escribí esta respuesta. –

0
  1. IronPython es como C# a su vez se basa en las bibliotecas prediseñados estáticas, 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 problemas futuros, pero nuevamente puede hacer lo mismo con Cpython.

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

11

La mayoría de las bibliotecas de Python científicas y numéricas que dependen de CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) trabajan principalmente bajo CPython, por lo que su mejor apuesta es pythonnet (otros nombres - Python.NET y Python para .NET). Lo mismo se aplica a los enlaces de GUy 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.

2

2016. En cuanto a

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

+0

Me sorprende que se haya elegido RPC entre diferentes procesos por motivos de rendimiento. Lo más probable es que CPython + .NET usando pythonnet en el mismo proceso sea más rápido que este enfoque. En cuanto a Zeroce ICE, tenga en cuenta que está licenciado por GPL, por lo que no es muy adecuado para aplicaciones comerciales. – denfromufa

+0

Una solución interesante, gracias. En cuanto a las licencias, existe una opción comercial para ICE: https://zeroc.com/licensing – Atorian

0

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.