Udvikling på IronPython, en Python-implementering, der kører på .Net-frameworkets Common Language Runtime (CLR), får et skud i armen takket være projektet, der for nylig skiftede hænder til en ny udviklingsleder.
Jeff Hardy, tidligere ledende IronPython-udvikler, bekræftede overgangen på Ironpython-brugerens mailingliste tidligere på denne måned. "Af mange grunde har jeg bare ikke tid lige nu til at give IronPython den opmærksomhed, det fortjener," skrev Hardy, "så jeg overgiver kontrol over projektet til [andre projektbidragere] Alex Earl og Benedikt Eggers."
En Python til .Net og omvendt
IronPython, skrevet i C #, er ikke kun beregnet til at køre Python-programmer på lager. Det kan give Python-programmører en bro til eksisterende .Net-applikationer og objekter. Bedst af alt kan disse objekter importeres og håndteres med samme syntaks og idiomer som oprindelige Python-objekter.
Udviklingen på IronPython er utvivlsomt bremset i løbet af de sidste par år. Den sidste store udgivelse var for Python 2.7.5 i slutningen af 2014. Python 3 blev ikke understøttet af IronPython - en stor ulempe, da Python 2 ikke længere understøttes fra 2020, og Python 3 er den etablerede efterfølger.
På et møde på udviklerchatwebstedet Gitter, Earl, Eggers og andre, har de mest presserende problemer, der står over for projektet, kørt ud, når det bevæger sig fremad: hvad skal man gøre ved udestående IronPython-problemer på CodePlex; hvilken slags udgivelsesplan skal implementeres og hvilken slags køreplan der skal udarbejdes til IronPython 3.
Et andet problem, der kom op i diskussioner, var, hvordan man implementerer support til Python-biblioteker, der bruger C-udvidelser. Hvis IronPython skal have et bredest muligt publikum, er dette ikke en mulighed. Mange store Python-biblioteker, som Numpy, bruger C-udvidelser til hastighed, og de skal ideelt set fungere som de er i IronPython uden at skulle kompileres igen.
Den gode nyhed er, at der allerede er gjort noget arbejde inden for dette område, nemlig Ironclad, et projekt udtænkt for at tillade kompilerede CPython-udvidelser at fungere som de er i IronPython. Den dårlige nyhed er, at projektet ikke har set meget arbejde i lang tid og skal revideres kraftigt for at være nyttigt for moderne Python.
Af rubiner og GIL'er
Et andet problem, der kom op, var, hvordan man skulle håndtere et lignende projekt, der blev håndteret af det samme team: IronRuby, som er en .Net-implementering af Ruby, som navnet antyder. De to sprog er blevet udviklet sammen, da de stammer fra den samme indsats inden for Microsoft omkring Dynamic Language Runtime, og forblev i tæt nærhed, efter at Microsoft udelukkede dem til samfundsbaseret indsats i 2010.
Planen er at gøre IronRuby til sit eget projekt for at tiltrække sit eget udviklerpublikum. IronPython 2 vil også fortsat blive udviklet som et diskret projekt.
Fremtidig IronPython-udvikling kan vise sig at være frugtbar ved at give en måde at opfylde den mangeårige drøm om en hurtig, multicore-venlig Python-runtime. IronPython har ikke en Global Interpreter Lock (GIL), en funktion i mange Python-implementeringer, der er blevet beskyldt for at være en barriere for høj ydeevne.
Når det er sagt, gør det faktum, at IronPython ikke har GIL, det automatisk hurtigere; nogle IronPython-benchmarks er bedre end CPython, men andre er markant dårligere. For nu er det bare at bringe IronPython i fart med de nuværende grene af Python, både 2 og 3, burde være mission nok.
