IronPython contro Python .NET

Voglio accedere ad alcuni assembly .NET scritti in C # dal codice Python.

Una piccola ricerca ha mostrato che ho due scelte:

• IronPython con funzionalità di interfaccia .NET / supporto integrato
• Python con il pacchetto Python .NET

Quali sono i compromessi tra entrambe le soluzioni?

Se vuoi basare il tuo codice principalmente sul framework .NET, consiglio vivamente IronPython contro Python.NET. IronPython è praticamente .NET nativo, quindi funziona alla grande quando si integra con altri linguaggi .NET.

Python.NET è utile se si desidera integrare solo uno o due componenti da .NET in un'applicazione Python standard.

Ci sono differenze notevoli quando si utilizza IronPython, ma la maggior parte di esse sono piuttosto sottili. Python.NET utilizza il runtime CPython standard, quindi questa pagina Wiki è una discussione pertinente delle differenze tra le due implementazioni. Le maggiori differenze si verificano nel costo delle eccezioni, quindi alcune delle librerie Python standard non funzionano altrettanto bene in IronPython a causa della loro implementazione.

Pur concordando con le risposte fornite da Reed Copsey e Alex Martelli, vorrei sottolineare un'ulteriore differenza: il Global Interpreter Lock (GIL). Sebbene IronPython non abbia i limiti del GIL, CPython sì, quindi sembrerebbe che per quelle applicazioni in cui GIL è un collo di bottiglia, ad esempio in alcuni scenari multicore, IronPython ha un vantaggio su Python.NET.

Dalla documentazione di Python.NET:

Nota importante per gli embedder: Python non è a thread libero e utilizza un blocco interprete globale per consentire alle applicazioni multi-thread di interagire in modo sicuro con l'interprete Python. Molte più informazioni su questo sono disponibili nella documentazione dell'API C di Python sul www.python.orgsito web.

Quando si incorpora Python in un'applicazione gestita, è necessario gestire il GIL nello stesso modo in cui si incorpora Python in un'applicazione C o C ++.

Prima di interagire con uno qualsiasi degli oggetti o delle API forniti dallo Python.Runtimespazio dei nomi, il codice chiamante deve aver acquisito il blocco dell'interprete globale Python chiamando il PythonEngine.AcquireLockmetodo. L'unica eccezione a questa regola è il PythonEngine.Initializemetodo, che può essere chiamato all'avvio senza aver acquisito il GIL.

Al termine dell'utilizzo delle API Python, il codice gestito deve chiamare un corrispondente PythonEngine.ReleaseLockper rilasciare il GIL e consentire ad altri thread di utilizzare Python.

I metodi AcquireLocke ReleaseLocksono thin wrapper sulle funzioni PyGILState_Ensuree non gestite PyGILState_Releasedall'API Python e la documentazione per tali API si applica alle versioni gestite.

Un altro problema è il supporto IDE. CPython probabilmente ha un supporto IDE migliore al momento rispetto a IronPython, quindi questo potrebbe essere un fattore nella scelta dell'uno rispetto all'altro.

La maggior parte delle librerie Python scientifiche e numeriche che si basano su CPython C-API (numpy, scipy, matplotlib, pandas, cython, ecc.) Funzionano principalmente con CPython, quindi in tal caso la soluzione migliore è pythonnet (altri nomi - Python.NET e Python per .NET). Lo stesso vale per le associazioni GUI CPython come WxWidgets, PyQt / PySide, GTK, Kivy, ecc., Anche se sia pythonnet che IronPython possono utilizzare WPF e WinForms.

E infine IronPython non supporta ancora completamente Python 3.

IronPython è ".NET-native", quindi sarà preferibile se desideri integrare completamente il tuo codice Python con .NET fino in fondo; Python.NET funziona con Classic Python, quindi ti consente di mantenere la "lunghezza di mano" del tuo codice Python lontano da .NET corretto. (Nota che con questo codice puoi effettivamente utilizzare estensioni scritte per CPython dal tuo codice IronPython, quindi non è più una condizione discriminante).

IronPython proviene da Microsoft, quindi seguirò il mio istinto e lo userei per primo poiché devi presumere che funzionerà meglio con altre tecnologie MSFT.

Come per il 2016.

Nella mia azienda abbiamo usato IronPython, ma non eravamo soddisfatti delle prestazioni (principalmente uso della memoria - il garbage collector era troppo lento) così abbiamo deciso di passare a Python standard e integrarlo con .Net utilizzando Zeroce-s ICE.

IronPython, attualmente, non supporta Python 3.6 (solo 2.7)

da IronPython 3 "Le build di IronPython 3 non sono ancora fornite."

1. Ironpython è come C #, a sua volta si basa su librerie statiche precostruite mentre a differenza di C # è un linguaggio dinamico.

2. Cpython è come C ++ come Ironpython è un linguaggio dinamico e ha accesso a librerie dinamiche che a loro volta si traducono in essere costretti a scrivere tutto.

3. Ironpython è più veloce di C # in alcune aree ma non più veloce di Cpython, tuttavia puoi collegare Ironpython a qualsiasi linguaggio in modo da superare i problemi in arrivo, ma puoi fare lo stesso con Cpython.

Un linguaggio divertente, semplice e potente indipendentemente da ciò che scegli!

Iron Python è fondamentalmente Python 2.7 con supporto .net integrato, probabilmente non supporterà mai Python 3. Perde sulle librerie C e Python, tuttavia dal lato della svolta ha accesso a .net e può essere esteso con C #. Quindi, se usi già C #, Iron Python è un bonus.

Preferisco principalmente Python per .NET, perché IronPython è compilato come codice gestito, che può essere facilmente decompilato (cosa che odio di più), ma con py2exe o pyinstaller puoi compilare Python con il modulo NET come un'applicazione non gestita.