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.org
sito 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.Runtime
spazio dei
nomi, il codice chiamante deve aver acquisito il blocco dell'interprete globale Python chiamando il
PythonEngine.AcquireLock
metodo. L'unica eccezione a questa regola è il
PythonEngine.Initialize
metodo, 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.ReleaseLock
per rilasciare il GIL e consentire ad altri thread di utilizzare Python.
I
metodi AcquireLock
e ReleaseLock
sono thin wrapper sulle funzioni PyGILState_Ensure
e
non gestite PyGILState_Release
dall'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.