IronPython vs. Python .NET

Quero acessar alguns assemblies .NET escritos em C # a partir do código Python.

Uma pequena pesquisa mostrou que tenho duas opções:

• IronPython com capacidade / suporte de interface .NET integrado
• Python com o pacote Python .NET

Quais são os trade-offs entre as duas soluções?

Se você deseja basear seu código principalmente no .NET framework, eu recomendo o IronPython vs Python.NET. IronPython é basicamente .NET nativo - então funciona muito bem ao se integrar a outros idiomas .NET.

Python.NET é bom se você deseja integrar apenas um ou dois componentes do .NET em um aplicativo Python padrão.

Existem diferenças notáveis ​​ao usar o IronPython - mas a maioria delas são bastante sutis. Python.NET usa o tempo de execução CPython padrão, então esta página Wiki é uma discussão relevante das diferenças entre as duas implementações. As maiores diferenças ocorrem no custo das exceções - portanto, algumas das bibliotecas Python padrão não funcionam tão bem no IronPython devido à sua implementação.

Ao concordar com as respostas dadas por Reed Copsey e Alex Martelli, gostaria de apontar mais uma diferença - o Global Interpreter Lock (GIL). Enquanto o IronPython não tem as limitações do GIL, o CPython tem - então parece que, para aquelas aplicações onde o GIL é um gargalo, digamos em certos cenários multicore, o IronPython tem uma vantagem sobre o Python.NET.

Da documentação do Python.NET:

Nota importante para incorporadores: Python não é free-threaded e usa um bloqueio de interpretador global para permitir que aplicativos multi-threaded interajam com segurança com o interpretador Python. Muito mais informações sobre isso estão disponíveis na documentação da API Python C no www.python.org site.

Ao incorporar Python em um aplicativo gerenciado, você deve gerenciar o GIL da mesma forma que faria ao incorporar Python em um aplicativo C ou C ++.

Antes de interagir com qualquer um dos objetos ou APIs fornecidos pelo Python.Runtimenamespace, o código de chamada deve ter adquirido o bloqueio do interpretador global Python chamando o PythonEngine.AcquireLockmétodo. A única exceção a esta regra é o PythonEngine.Initializemétodo, que pode ser chamado na inicialização sem ter adquirido o GIL.

Quando terminar de usar as APIs do Python, o código gerenciado deve chamar um correspondente PythonEngine.ReleaseLockpara liberar o GIL e permitir que outros threads usem o Python.

Os métodos AcquireLocke ReleaseLocksão thin wrappers sobre as funções PyGILState_Ensuree não gerenciadas PyGILState_Releaseda API Python, e a documentação dessas APIs se aplica às versões gerenciadas.

Outro problema é o suporte IDE. CPython provavelmente tem um suporte IDE melhor no momento do que IronPython - então isso pode ser um fator na escolha de um ou outro.

A maioria das bibliotecas Python científicas e numéricas que contam com CPython C-API (numpy, scipy, matplotlib, pandas, cython, etc.) estão trabalhando principalmente em CPython, então, nesse caso, sua melhor aposta é pythonnet (outros nomes - Python.NET e Python para .NET). O mesmo é verdadeiro para ligações de GUI CPython, como WxWidgets, PyQt / PySide, GTK, Kivy, etc., embora tanto pythonnet quanto IronPython possam usar WPF e WinForms.

E, finalmente, o IronPython ainda não oferece suporte completo ao Python 3.

IronPython é "nativo do .NET" - portanto, será preferível se você quiser integrar totalmente o seu código Python com .NET totalmente; O Python.NET funciona com o Python Clássico, portanto, permite que você mantenha o "comprimento do braço" do código Python longe do .NET. (Observe que com este código você pode realmente usar extensões escritas para CPython a partir do seu código IronPython, de forma que essa não seja mais uma condição discriminatória).

IronPython vem da Microsoft, então eu iria com minha intuição e usaria aquele primeiro, já que você tem que assumir que ele funcionará melhor com outras tecnologias MSFT.

Quanto a 2016.

Na minha empresa, usamos IronPython, mas não estávamos satisfeitos com o desempenho (principalmente uso de memória - o coletor de lixo era muito lento), então decidimos mudar para o Python padrão e integrá-lo ao .Net usando ICE do Zeroce.

IronPython, atualmente, não oferece suporte a Python 3.6 (apenas 2.7)

do IronPython 3 "Builds do IronPython 3 ainda não foram fornecidos."

1. Ironpython é como C #, por sua vez, depende de bibliotecas pré-construídas estáticas, enquanto ao contrário de C # é uma linguagem dinâmica.

2. Cpython é como C ++ como Ironpython é uma linguagem dinâmica e tem acesso a bibliotecas dinâmicas que por sua vez se traduzem em ser forçado a escrever tudo.

3. Ironpython é mais rápido do que C # em certas áreas, mas não mais rápido do que Cpython; no entanto, você pode vincular Ironpython a qualquer linguagem, evitando problemas futuros, mas, novamente, você pode fazer o mesmo com o Cpython.

Uma linguagem divertida, simples e poderosa independentemente da sua escolha!

Iron Python é basicamente Python 2.7 com suporte a .net integrado, provavelmente nunca oferecerá suporte a Python 3. Ele perde as bibliotecas C e Python, no entanto, tem acesso a .net e pode ser estendido com C #. Portanto, se você já usa C #, Iron Python é um bônus.

Eu prefiro principalmente Python para .NET, porque IronPython é compilado como código gerenciado, que pode ser facilmente descompilado (o que eu mais odeio), mas com py2exe ou pyinstaller você pode compilar Python com módulo NET como um aplicativo não gerenciado.