IronPython vs. Python .NET

Ich möchte über Python-Code auf einige in C # geschriebene .NET-Assemblys zugreifen.

Eine kleine Untersuchung ergab, dass ich zwei Möglichkeiten habe:

• IronPython mit integrierter .NET-Schnittstellenfunktion / -unterstützung
• Python mit dem Python .NET- Paket

Was sind die Kompromisse zwischen beiden Lösungen?

Wenn Sie Ihren Code hauptsächlich auf dem .NET-Framework basieren möchten, würde ich IronPython vs Python.NET wärmstens empfehlen. IronPython ist so ziemlich natives .NET - daher funktioniert es einfach hervorragend, wenn es in andere .NET-Sprachen integriert wird.

Python.NET ist gut, wenn Sie nur eine oder zwei Komponenten aus .NET in eine Standard-Python-Anwendung integrieren möchten.

Es gibt bemerkenswerte Unterschiede bei der Verwendung von IronPython - aber die meisten davon sind ziemlich subtil. Python.NET verwendet die Standard-CPython-Laufzeit, daher ist diese Wiki-Seite eine relevante Diskussion der Unterschiede zwischen den beiden Implementierungen. Die größten Unterschiede bestehen bei den Kosten für Ausnahmen. Daher funktionieren einige der Standard-Python-Bibliotheken in IronPython aufgrund ihrer Implementierung nicht so gut.

Obwohl ich den Antworten von Reed Copsey und Alex Martelli zustimme, möchte ich auf einen weiteren Unterschied hinweisen - das Global Interpreter Lock (GIL). Während IronPython nicht die Einschränkungen der GIL aufweist, hat CPython dies - so scheint es, dass IronPython für Anwendungen, bei denen die GIL ein Engpass ist, beispielsweise in bestimmten Multicore-Szenarien, einen Vorteil gegenüber Python.NET hat.

Aus der Python.NET-Dokumentation:

Wichtiger Hinweis für Einbettungsprogramme: Python ist kein Thread-Thread und verwendet eine globale Interpretersperre, damit Multithread-Anwendungen sicher mit dem Python-Interpreter interagieren können. Weitere Informationen hierzu finden Sie in der Python C-API-Dokumentation auf der www.python.orgWebsite.

Wenn Sie Python in eine verwaltete Anwendung einbetten, müssen Sie die GIL genauso verwalten wie beim Einbetten von Python in eine C- oder C ++ - Anwendung.

Vor der Interaktion mit einem der vom Python.RuntimeNamespace bereitgestellten Objekte oder APIs muss der aufrufende Code die globale Python-Interpretersperre durch Aufrufen der PythonEngine.AcquireLockMethode erhalten haben. Die einzige Ausnahme von dieser Regel ist die PythonEngine.Initialize Methode, die beim Start aufgerufen werden kann, ohne die GIL erworben zu haben.

Wenn Sie die Python-APIs nicht mehr verwenden, muss der verwaltete Code einen entsprechenden Code aufrufen PythonEngine.ReleaseLock , um die GIL freizugeben und anderen Threads die Verwendung von Python zu ermöglichen.

Die AcquireLockund ReleaseLock -Methoden sind Thin Wrapper über die nicht verwalteten PyGILState_Ensureund PyGILState_ReleaseFunktionen der Python-API, und die Dokumentation für diese APIs gilt für die verwalteten Versionen.

Ein weiteres Problem ist die IDE-Unterstützung. CPython hat derzeit wahrscheinlich eine bessere IDE-Unterstützung als IronPython - daher kann dies ein Faktor bei der Auswahl eines über dem anderen sein.

Die meisten wissenschaftlichen und numerischen Python-Bibliotheken, die auf CPython C-API basieren (numpy, scipy, matplotlib, pandas, cython usw.), arbeiten hauptsächlich unter CPython. In diesem Fall ist Pythonnet (andere Namen - Python.NET) die beste Wahl und Python für .NET). Gleiches gilt für CPython-GUI-Bindungen wie WxWidgets, PyQt / PySide, GTK, Kivy usw., obwohl sowohl Pythonnet als auch IronPython WPF und WinForms verwenden können.

Und schließlich unterstützt IronPython Python 3 noch nicht vollständig.

IronPython ist ".NET-native". Daher ist es vorzuziehen, wenn Sie Ihren Python-Code vollständig in .NET integrieren möchten. Python.NET funktioniert mit klassischem Python, sodass Sie die "Armlänge" Ihres Python-Codes von .NET fernhalten können. (Beachten Sie, dass Sie mit diesem Code tatsächlich Erweiterungen verwenden können, die für CPython aus Ihrem IronPython-Code geschrieben wurden. Dies ist also keine diskriminierende Bedingung mehr.)

IronPython stammt von Microsoft, daher würde ich mich zuerst für diesen entscheiden, da Sie davon ausgehen müssen, dass er mit anderen MSFT-Technologien besser funktioniert.

Wie für 2016.

In meiner Firma haben wir IronPython verwendet, aber wir waren mit der Leistung nicht zufrieden (hauptsächlich Speichernutzung - Garbage Collector war zu langsam), sodass wir beschlossen, auf Standard-Python umzusteigen und es mit Zeroces ICE in .Net zu integrieren.

IronPython unterstützt derzeit Python 3.6 nicht (nur 2.7)

von IronPython 3 "Builds von IronPython 3 sind noch nicht verfügbar."

1. Ironpython ist wie C # und basiert auf statischen vorgefertigten Bibliotheken, während C # im Gegensatz zu C # eine dynamische Sprache ist.

2. Cpython ist wie C ++, wie Ironpython eine dynamische Sprache ist und Zugriff auf dynamische Bibliotheken hat, was wiederum bedeutet, dass man gezwungen ist, alles zu schreiben.

3. Ironpython ist in bestimmten Bereichen schneller als C #, aber nicht schneller als Cpython. Sie können Ironpython jedoch mit jeder Sprache verknüpfen, um Probleme zu lösen, aber Sie können dies auch mit Cpython tun.

Eine lustige, einfache und mächtige Sprache, egal was Sie wählen!

Iron Python ist im Grunde Python 2.7 mit integrierter .net-Unterstützung. Es wird wahrscheinlich niemals Python 3 unterstützen. Es verliert an C- und Python-Bibliotheken, hat jedoch auf der Twist-Seite Zugriff auf .net und kann mit C # erweitert werden. Wenn Sie also bereits C # verwenden, ist Iron Python ein Bonus.

Ich bevorzuge hauptsächlich Python für .NET, da IronPython als verwalteter Code kompiliert wird, der leicht dekompiliert werden kann (was ich am meisten hasse), aber mit py2exe oder pyinstaller können Sie Python mit dem NET-Modul als nicht verwaltete Anwendung kompilieren.