Programmering

Python for .Net reiser seg fra de døde

Utvikling på IronPython, en Python-implementering som kjører på .Net-rammeverket Common Language Runtime (CLR), får et skudd i armen takket være at prosjektet nylig byttet hender til en ny utvikling.

Jeff Hardy, tidligere ledende IronPython-utvikler, bekreftet overgangen på Ironpython-brukerens adresseliste tidligere denne måneden. "Av mange grunner har jeg bare ikke tid akkurat nå til å gi IronPython den oppmerksomheten den fortjener," skrev Hardy, "så jeg gir kontrollen over prosjektet til [andre prosjektbidragere] Alex Earl og Benedikt Eggers."

En Python for .Net, og omvendt

IronPython, skrevet i C #, er ikke bare ment å kjøre lager Python-programmer. Det kan gi Python-programmerere en bro til eksisterende .Net-applikasjoner og objekter. Best av alt, disse objektene kan importeres og håndteres med samme syntaks og uttrykk som innfødte Python-objekter.

Utviklingen på IronPython har utvilsomt avtatt de siste par årene. Den siste store utgivelsen var for Python 2.7.5, på slutten av 2014. Python 3 ble ikke støttet av IronPython - en stor ulempe siden Python 2 ikke lenger vil bli støttet fra og med 2020, og Python 3 er den etablerte etterfølgeren.

I et møte på utviklerchattesiden Gitter, Earl, Eggers og andre, har de mest presserende problemene som prosjektet står overfor når det går fremover: hva skal jeg gjøre med fremragende IronPython-problemer på CodePlex; hva slags utgivelsesplan å implementere; og hva slags veikart du skal lage for IronPython 3.

En annen sak som kom opp i diskusjoner var hvordan man implementerer støtte for Python-biblioteker som bruker C-utvidelser. Hvis IronPython skal ha et bredest mulig publikum, er dette ikke et alternativ. Mange store Python-biblioteker, som Numpy, bruker C-utvidelser for hastighet, og de bør ideelt sett fungere som de er i IronPython uten å måtte kompileres på nytt.

Den gode nyheten er at noe arbeid allerede er gjort i dette området, nemlig Ironclad, et prosjekt utviklet for å la kompilerte CPython-utvidelser fungere som de er i IronPython. Den dårlige nyheten er at prosjektet ikke har sett mye arbeid på lenge, og må revideres tungt for å være nyttig for moderne Python.

Av rubiner og GIL

Et annet problem som kom opp var hvordan man skulle håndtere et lignende prosjekt håndtert av samme team: IronRuby, som er en .Net-implementering av Ruby, som navnet antyder. De to språkene er utviklet samtidig, siden de stammer fra den samme innsatsen innen Microsoft rundt Dynamic Language Runtime, og forble i umiddelbar nærhet etter at Microsoft utspilte dem til samfunnsdrevet innsats i 2010.

Planen er å gjøre IronRuby til sitt eget prosjekt for å tiltrekke sitt eget utviklerpublikum. IronPython 2 vil også fortsette å bli utviklet som et diskret prosjekt.

Fremtidig IronPython-utvikling kan vise seg å være fruktbar ved å tilby en måte å oppfylle den mangeårige drømmen om en rask, flerkjernevennlig Python-kjøretid. IronPython har ikke en Global Interpreter Lock (GIL), en funksjon i mange Python-implementeringer som har fått skylden for å være en barriere for høy ytelse.

Når det er sagt, det faktum at IronPython ikke har GIL, gjør det ikke automatisk raskere; noen IronPython-referanser er bedre enn CPython, men andre er markant dårligere. For nå, bare å bringe IronPython opp i fart med de nåværende grenene av Python, 2 og 3, burde være oppdrag nok.

$config[zx-auto] not found$config[zx-overlay] not found