Quero acessar alguns assemblies .NET escritos em C # a partir do código Python.
Uma pequena pesquisa mostrou que tenho duas opções:
Quais são os trade-offs entre as duas soluções?
Respostas:
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.orgsite.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 oPythonEngine.AcquireLockmétodo. A única exceção a esta regra é oPythonEngine.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
AcquireLockeReleaseLocksão thin wrappers sobre as funçõesPyGILState_Ensuree não gerenciadasPyGILState_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."
Ironpython é como C #, por sua vez, depende de bibliotecas pré-construídas estáticas, enquanto ao contrário de C # é uma linguagem dinâmica.
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.
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.