Python per .Net risorge dalla morte

Lo sviluppo su IronPython, un'implementazione Python che gira sul Common Language Runtime (CLR) del framework .Net, sta ottenendo un colpo nel braccio grazie al progetto che recentemente è passato di mano a un nuovo responsabile dello sviluppo.

Jeff Hardy, ex sviluppatore capo di IronPython, ha confermato la transizione nella mailing list degli utenti di Ironpython all'inizio di questo mese. "Per molte ragioni non ho il tempo in questo momento di dare a IronPython l'attenzione che merita", ha scritto Hardy, "quindi sto affidando il controllo del progetto a [colleghi collaboratori del progetto] Alex Earl e Benedikt Eggers."

Un Python per .Net e viceversa

IronPython, scritto in C #, non è pensato solo per eseguire programmi Python di serie. Può fornire ai programmatori Python un ponte per applicazioni e oggetti .Net esistenti. Soprattutto, questi oggetti possono essere importati e gestiti con la stessa sintassi e idiomi degli oggetti Python nativi.

Lo sviluppo su IronPython è indiscutibilmente rallentato negli ultimi due anni. L'ultima versione principale era per Python 2.7.5, alla fine del 2014. Python 3 non era supportato da IronPython - un grave inconveniente poiché Python 2 non sarà più supportato a partire dal 2020 e Python 3 è il successore stabilito.

In una riunione sul sito di chat degli sviluppatori Gitter, Earl, Eggers e altri hanno discusso i problemi più urgenti che il progetto deve affrontare man mano che avanza: cosa fare in caso di problemi IronPython in sospeso su CodePlex; che tipo di programma di rilascio implementare; e che tipo di road map ideare per IronPython 3.

Un altro problema emerso durante le discussioni è stato come implementare il supporto per le librerie Python che utilizzano estensioni C. Se IronPython vuole avere il pubblico più ampio possibile, questa non è un'opzione. Molte delle principali librerie Python, come Numpy, utilizzano le estensioni C per la velocità e dovrebbero idealmente funzionare così come sono in IronPython senza bisogno di essere ricompilate.

La buona notizia è che in quest'area è già stato fatto del lavoro, ovvero Ironclad, un progetto ideato per consentire alle estensioni CPython compilate di funzionare così come sono in IronPython. La cattiva notizia è che il progetto non ha visto molto lavoro da molto tempo e dovrà essere pesantemente rivisto per essere utile per il moderno Python.

Di rubini e GIL

Un altro problema che è emerso è stato come affrontare un progetto simile gestito dallo stesso team: IronRuby, che è un'implementazione .Net di Ruby, come suggerisce il nome. I due linguaggi sono stati sviluppati congiuntamente, poiché hanno avuto origine dagli stessi sforzi all'interno di Microsoft intorno al Dynamic Language Runtime e sono rimasti molto vicini dopo che Microsoft li ha scorporati in iniziative guidate dalla comunità nel 2010.

Il piano è quello di rendere IronRuby il proprio progetto per attirare il proprio pubblico di sviluppatori. IronPython 2 continuerà anche a essere sviluppato come progetto discreto.

Il futuro sviluppo di IronPython potrebbe rivelarsi fruttuoso fornendo un modo per realizzare il sogno di lunga data di un runtime Python veloce e compatibile con il multicore. IronPython non ha un Global Interpreter Lock (GIL), una caratteristica di molte implementazioni di Python che è stata accusata di essere un ostacolo alle alte prestazioni.

Detto questo, il fatto che IronPython non abbia GIL non lo rende automaticamente più veloce; alcuni benchmark IronPython sono migliori di CPython, ma altri sono notevolmente peggiori. Per ora, portare semplicemente IronPython al passo con gli attuali rami di Python, 2 e 3 allo stesso modo, dovrebbe essere una missione sufficiente.