IronPython contre Python .NET

Je souhaite accéder à certains assemblys .NET écrits en C # à partir de code Python.

Une petite recherche a montré que j'avais deux choix:

• IronPython avec capacité d'interface .NET / prise en charge intégrée
• Python avec le package Python .NET

Quels sont les compromis entre les deux solutions?

Si vous souhaitez principalement baser votre code sur le framework .NET, je recommande vivement IronPython vs Python.NET. IronPython est à peu près .NET natif - il fonctionne donc très bien lors de l'intégration avec d'autres langages .NET.

Python.NET est idéal si vous souhaitez simplement intégrer un ou deux composants de .NET dans une application Python standard.

Il existe des différences notables lors de l'utilisation d'IronPython - mais la plupart d'entre elles sont assez subtiles. Python.NET utilise le runtime CPython standard, donc cette page Wiki est une discussion pertinente sur les différences entre les deux implémentations. Les plus grandes différences se produisent dans le coût des exceptions - de sorte que certaines des bibliothèques Python standard ne fonctionnent pas aussi bien dans IronPython en raison de leur implémentation.

Tout en étant d'accord avec les réponses données par Reed Copsey et Alex Martelli, je voudrais souligner une autre différence: le Global Interpreter Lock (GIL). Alors qu'IronPython n'a pas les limites du GIL, CPython en a - il semblerait donc que pour les applications où le GIL est un goulot d'étranglement, par exemple dans certains scénarios multicœurs, IronPython a un avantage sur Python.NET.

À partir de la documentation Python.NET:

Remarque importante pour les intégrateurs: Python n'est pas à thread libre et utilise un verrou d'interpréteur global pour permettre aux applications multithreads d'interagir en toute sécurité avec l'interpréteur Python. De plus amples informations à ce sujet sont disponibles dans la documentation de l'API Python C sur le www.python.orgsite Web.

Lorsque vous intégrez Python dans une application gérée, vous devez gérer le GIL de la même manière que vous le feriez lors de l'incorporation de Python dans une application C ou C ++.

Avant d'interagir avec l'un des objets ou API fournis par l' Python.Runtimeespace de noms, le code appelant doit avoir acquis le verrou d'interpréteur global Python en appelant la PythonEngine.AcquireLockméthode. La seule exception à cette règle est la PythonEngine.Initializeméthode, qui peut être appelée au démarrage sans avoir acquis le GIL.

Une fois l'utilisation des API Python terminée, le code managé doit appeler un correspondant PythonEngine.ReleaseLockpour libérer le GIL et permettre à d'autres threads d'utiliser Python.

Les méthodes AcquireLocket ReleaseLocksont des wrappers légers sur les fonctions PyGILState_Ensureet non managées PyGILState_Releasede l'API Python, et la documentation de ces API s'applique aux versions gérées.

Un autre problème est le support IDE. CPython a probablement un meilleur support IDE à l'heure actuelle qu'IronPython - cela peut donc être un facteur dans le choix de l'un par rapport à l'autre.

La plupart des bibliothèques Python scientifiques et numériques qui reposent sur CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) fonctionnent principalement sous CPython, donc dans ce cas, votre meilleur pari est pythonnet (autres noms - Python.NET et Python pour .NET). Il en va de même pour les liaisons GUI CPython telles que WxWidgets, PyQt / PySide, GTK, Kivy, etc., bien que pythonnet et IronPython puissent utiliser WPF et WinForms.

Enfin, IronPython ne prend pas encore totalement en charge Python 3.

IronPython est ".NET natif" - il sera donc préférable si vous souhaitez intégrer complètement votre code Python avec .NET jusqu'au bout; Python.NET fonctionne avec Python classique, donc il vous permet de garder le "bras de fer" de votre code Python loin de .NET proprement dit. (Notez qu'avec ce code, vous pouvez en fait utiliser des extensions écrites pour CPython à partir de votre code IronPython, ce n'est donc plus une condition discriminante).

IronPython vient de Microsoft, donc j'irais avec mon instinct et utiliserais celui-là en premier, car vous devez supposer qu'il fonctionnera mieux avec d'autres technologies MSFT.

Comme pour 2016.

Dans mon entreprise, nous avons utilisé IronPython, mais nous n'étions pas satisfaits des performances (principalement l'utilisation de la mémoire - le ramasse-miettes était trop lent), nous avons donc décidé de passer à Python standard et de l'intégrer à .Net en utilisant Zeroce-s ICE.

IronPython, actuellement, ne prend pas en charge Python 3.6 (seulement 2.7)

from IronPython 3 "Les versions d'IronPython 3 ne sont pas encore fournies."

1. Ironpython est comme C # à son tour, il s'appuie sur des bibliothèques prédéfinies statiques alors que contrairement à C #, il est un langage dynamique.

2. Cpython est comme C ++ comme Ironpython est un langage dynamique et a accès à des bibliothèques dynamiques qui à son tour se traduisent par l'obligation de tout écrire.

3. Ironpython est plus rapide que C # dans certains domaines mais pas plus rapide que Cpython, mais vous pouvez lier Ironpython à n'importe quel langage afin de surmonter les problèmes à venir, mais vous pouvez encore faire de même avec Cpython.

Un langage drôle, simple et puissant quel que soit votre choix!

Iron Python est fondamentalement Python 2.7 avec un support .net intégré, il ne supportera probablement jamais Python 3. Il perd sur les bibliothèques C et Python, mais du côté torsion a accès à .net et peut être étendu avec C #. Donc, si vous utilisez déjà C #, Iron Python est un bonus.

Je préfère principalement Python pour .NET, car IronPython est compilé en tant que code managé, qui peut être facilement décompilé (ce que je déteste le plus), mais avec py2exe ou pyinstaller, vous pouvez compiler Python avec le module NET en tant qu'application non gérée.