IronPython kontra Python .NET

Chcę uzyskać dostęp do niektórych zestawów .NET napisanych w C # z kodu Pythona.

Małe badania wykazały, że mam dwie możliwości:

• IronPython z wbudowanym interfejsem .NET
• Python z pakietem Python .NET

Jakie są kompromisy między oboma rozwiązaniami?

Jeśli chcesz oprzeć swój kod głównie na frameworku .NET, gorąco polecam IronPython vs Python.NET. IronPython jest prawie natywnym .NET - więc po prostu świetnie się integruje z innymi językami .NET.

Python.NET jest dobry, jeśli chcesz po prostu zintegrować jeden lub dwa komponenty z .NET w standardowej aplikacji Pythona.

Istnieją znaczące różnice podczas korzystania z IronPython - ale większość z nich jest dość subtelna. Python.NET korzysta ze standardowego środowiska wykonawczego CPython, więc ta strona Wiki jest odpowiednim omówieniem różnic między tymi dwiema implementacjami. Największe różnice występują w koszcie wyjątków - dlatego niektóre ze standardowych bibliotek Pythona nie działają tak dobrze w IronPythonie ze względu na ich implementację.

Zgadzając się z odpowiedziami udzielonymi przez Reeda Copseya i Alexa Martellego, chciałbym zwrócić uwagę na jeszcze jedną różnicę - Global Interpreter Lock (GIL). Chociaż IronPython nie ma ograniczeń GIL, CPython ma - więc wydaje się, że w tych aplikacjach, w których GIL jest wąskim gardłem, powiedzmy w niektórych scenariuszach wielordzeniowych, IronPython ma przewagę nad Python.NET.

Z dokumentacji Python.NET:

Ważna uwaga dla osób osadzających: Python nie jest wolnym wątkiem i używa globalnej blokady interpretera, aby umożliwić aplikacjom wielowątkowym bezpieczną interakcję z interpreterą Pythona. Znacznie więcej informacji na ten temat można znaleźć w dokumentacji interfejsu API języka Python C w www.python.orgWitrynie.

Podczas osadzania języka Python w zarządzanej aplikacji musisz zarządzać GIL w taki sam sposób, jak w przypadku osadzania języka Python w aplikacji C lub C ++.

Przed rozpoczęciem interakcji z jakimikolwiek obiektami lub interfejsami API udostępnianymi przez Python.Runtimeprzestrzeń nazw kod wywołujący musi uzyskać globalną blokadę interpretera języka Python przez wywołanie PythonEngine.AcquireLockmetody. Jedynym wyjątkiem od tej reguły jest PythonEngine.Initializemetoda, którą można wywołać podczas uruchamiania bez posiadania GIL.

Po zakończeniu korzystania z interfejsów API PythonEngine.ReleaseLockjęzyka Python kod zarządzany musi wywołać odpowiedni, aby zwolnić GIL i zezwolić innym wątkom na korzystanie z Pythona.

AcquireLockI ReleaseLock metody są cienkie owijarki nad niekontrolowana PyGILState_Ensurei PyGILState_Releasefunkcji z API Pythona, a dokumentacja dla tych API dotyczy zarządzanych wersjach.

Kolejną kwestią jest obsługa IDE. CPython prawdopodobnie ma obecnie lepszą obsługę IDE niż IronPython - więc może to być czynnik przy wyborze jednego z nich.

Większość naukowych i numerycznych bibliotek Pythona, które opierają się na CPython C-API (numpy, scipy, matplotlib, pandas, cython itp.) Działa głównie pod CPythonem, więc w takim przypadku najlepszym rozwiązaniem jest pythonnet (inne nazwy - Python.NET i Python dla .NET). To samo dotyczy powiązań GUI CPythona, takich jak WxWidgets, PyQt / PySide, GTK, Kivy itp., Chociaż zarówno pythonnet, jak i IronPython mogą używać WPF i WinForms.

I wreszcie IronPython nie obsługuje jeszcze w pełni Pythona 3.

IronPython jest „natywny dla .NET” - więc najlepiej będzie, jeśli chcesz całkowicie zintegrować swój kod Pythona z .NET; Python.NET współpracuje z klasycznym Pythonem, więc pozwala ci trzymać kod Pythona z dala od właściwego .NET. (Zauważ, że z tym kodem możesz faktycznie używać rozszerzeń napisanych dla CPython z twojego kodu IronPython, więc nie jest to już warunek dyskryminujący).

IronPython pochodzi od Microsoftu, więc poszedłbym z moimi przeczuciami i użyłbym tego jako pierwszego, ponieważ musisz założyć, że będzie lepiej współpracował z innymi technologiami MSFT.

Jak na rok 2016.

W mojej firmie używaliśmy IronPython, ale nie byliśmy zadowoleni z wydajności (głównie użycie pamięci - garbage collector był zbyt wolny), więc zdecydowaliśmy się przejść na standardowy Python i zintegrować go z .Net za pomocą Zeroce-s ICE.

IronPython obecnie nie obsługuje Pythona 3.6 (tylko 2.7)

z IronPython 3 „Kompilacje IronPython 3 nie są jeszcze dostępne”.

1. Ironpython jest podobny do C #, z kolei opiera się na statycznych, wstępnie zbudowanych bibliotekach, podczas gdy w przeciwieństwie do C # jest językiem dynamicznym.

2. Cpython jest podobny do C ++, jak Ironpython jest językiem dynamicznym i ma dostęp do dynamicznych bibliotek, co z kolei oznacza konieczność pisania wszystkiego.

3. Ironpython jest szybszy niż C # w niektórych obszarach, ale nie szybszy niż Cpython, jednak możesz połączyć Ironpython z dowolnym językiem, w ten sposób przezwyciężając nadchodzące problemy, ale z drugiej strony możesz zrobić to samo z Cpythonem.

Zabawny, prosty i mocny język, niezależnie od tego, co wybierzesz!

Iron Python to w zasadzie Python 2.7 ze zintegrowaną obsługą .net, prawdopodobnie nigdy nie będzie obsługiwał Pythona 3. Przegrywa na bibliotekach C i Python, jednak po stronie twist ma dostęp do .net i może być rozszerzany za pomocą C #. Więc jeśli używasz już C #, Iron Python jest bonusem.

Preferuję głównie Pythona dla .NET, ponieważ IronPython jest kompilowany jako kod zarządzany, który można łatwo dekompilować (czego najbardziej nienawidzę), ale za pomocą py2exe lub pyinstaller można skompilować Pythona z modułem NET jako niezarządzaną aplikacją.