IronPython против Python .NET

Я хочу получить доступ к некоторым сборкам .NET, написанным на C #, из кода Python.

Небольшое исследование показало, что у меня есть два варианта:

• IronPython с возможностью интерфейса .NET / встроенной поддержкой
• Python с пакетом Python .NET

Каковы компромиссы между обоими решениями?

Если вы хотите в основном основывать свой код на платформе .NET, я настоятельно рекомендую IronPython против Python.NET. IronPython в значительной степени является родным .NET, поэтому он отлично работает при интеграции с другими языками .NET.

Python.NET хорош, если вы хотите просто интегрировать один или два компонента из .NET в стандартное приложение Python.

При использовании IronPython есть заметные различия, но большинство из них довольно тонкие. Python.NET использует стандартную среду выполнения CPython, поэтому на этой странице Wiki подробно обсуждаются различия между двумя реализациями. Наибольшие различия возникают в стоимости исключений - поэтому некоторые стандартные библиотеки Python не работают так же хорошо в IronPython из-за их реализации.

Соглашаясь с ответами Рида Копси и Алекса Мартелли, я хотел бы отметить еще одно отличие - глобальную блокировку интерпретатора (GIL). В то время как IronPython не имеет ограничений GIL, CPython имеет - поэтому может показаться, что для тех приложений, где GIL является узким местом, скажем, в определенных многоядерных сценариях, IronPython имеет преимущество перед Python.NET.

Из документации Python.NET:

Важное примечание для встраиваемых программ: Python не является свободнопоточным и использует глобальную блокировку интерпретатора, чтобы позволить многопоточным приложениям безопасно взаимодействовать с интерпретатором Python. Более подробная информация об этом доступна в документации Python C API на www.python.orgвеб-сайте.

При встраивании Python в управляемое приложение вы должны управлять GIL точно так же, как при встраивании Python в приложение C или C ++.

Перед взаимодействием с любым из объектов или API, предоставляемых Python.Runtimeпространством имен, вызывающий код должен получить глобальную блокировку интерпретатора Python путем вызова PythonEngine.AcquireLockметода. Единственным исключением из этого правила является PythonEngine.Initializeметод, который можно вызывать при запуске без получения GIL.

По завершении использования API-интерфейсов Python управляемый код должен вызвать соответствующий вызов, PythonEngine.ReleaseLockчтобы выпустить GIL и разрешить другим потокам использовать Python.

AcquireLockИ ReleaseLock методы представляют собой тонкие оболочки над неуправляемыми PyGILState_Ensureи PyGILState_Releaseфункциями из API Python и документация для этих API , относится к управляемым версиям.

Другой вопрос - поддержка IDE. CPython, вероятно, в настоящее время имеет лучшую поддержку IDE, чем IronPython, поэтому это может быть фактором при выборе одного из них.

Большинство научных и числовых библиотек Python, которые полагаются на CPython C-API (numpy, scipy, matplotlib, pandas, cython и т. Д.), Работают в основном под CPython, поэтому в этом случае лучше всего использовать pythonnet (другие названия - Python.NET. и Python для .NET). То же самое верно для привязок графического интерфейса пользователя CPython, таких как WxWidgets, PyQt / PySide, GTK, Kivy и т. Д., Хотя и pythonnet, и IronPython могут использовать WPF и WinForms.

И, наконец, IronPython еще не полностью поддерживает Python 3.

IronPython является «родным для .NET», поэтому будет предпочтительнее, если вы хотите полностью интегрировать свой код Python с .NET; Python.NET работает с классическим Python, поэтому он позволяет держать ваш код Python на расстоянии вытянутой руки от собственно .NET. (Обратите внимание, что с этим кодом вы действительно можете использовать расширения, написанные для CPython из вашего кода IronPython, так что это больше не является дискриминационным условием).

IronPython разработан Microsoft, поэтому я бы решил использовать его в первую очередь, поскольку вы должны предположить, что он будет лучше работать с другими технологиями MSFT.

Что касается 2016 года.

В моей компании мы использовали IronPython, но нас не удовлетворила производительность (в основном использование памяти - сборщик мусора работал слишком медленно), поэтому мы решили перейти на стандартный Python и интегрировать его с .Net с помощью Zeroce-s ICE.

IronPython в настоящее время не поддерживает Python 3.6 (только 2.7)

из IronPython 3 «Сборки IronPython 3 еще не предусмотрены».

1. Ironpython похож на C #, в свою очередь, он полагается на статические предварительно созданные библиотеки, в то время как в отличие от C # это динамический язык.

2. Cpython похож на C ++, как Ironpython - это динамический язык и имеет доступ к динамическим библиотекам, что, в свою очередь, означает необходимость писать все.

3. Ironpython быстрее C # в определенных областях, но не быстрее, чем Cpython, однако вы можете связать Ironpython с любым языком, тем самым преодолевая возникающие проблемы, но опять же вы можете сделать то же самое с Cpython.

Веселый, простой и мощный язык, какой бы вы ни выбрали!

Iron Python - это в основном Python 2.7 со встроенной поддержкой .net, он, вероятно, никогда не будет поддерживать Python 3. Он проигрывает библиотекам C и Python, однако, с другой стороны, имеет доступ к .net и может быть расширен с помощью C #. Так что, если вы уже используете C #, то Iron Python - это бонус.

Я в основном предпочитаю Python для .NET, потому что IronPython компилируется как управляемый код, который можно легко декомпилировать (что я больше всего ненавижу), но с py2exe или pyinstaller вы можете скомпилировать Python с модулем NET как неуправляемое приложение.