Programavimas

„Neton“ prisikelia iš numirusių

„IronPython“, „Python“ diegimas, kuris veikia .Net sistemos „Common Language Runtime“ (CLR), yra tobulas, nes projektas neseniai pakeitė rankas į naują kūrimo lyderį.

Jeffas Hardy, buvęs pagrindinis „IronPython“ kūrėjas, anksčiau šį mėnesį patvirtino perėjimą prie „Ironpython“ vartotojų pašto adresų sąrašo. „Dėl daugelio priežasčių šiuo metu tiesiog neturiu laiko skirti„ IronPython “nusipelniusio dėmesio, - rašė Hardy, - todėl aš perduodu projekto kontrolę [kitiems projekto dalyviams] Alexui Earlui ir Benediktui Eggersui.

„Python“ .Net ir atvirkščiai

C # parašytas „IronPython“ skirtas ne tik paleisti „Python“ programas. Tai gali suteikti „Python“ programuotojams tiltą į esamas .Net programas ir objektus. Geriausia, kad tuos objektus galima importuoti ir tvarkyti naudojant tą pačią sintaksę ir idiomas kaip vietinius „Python“ objektus.

„IronPython“ plėtra neabejotinai sulėtėjo per pastaruosius porą metų. Paskutinis svarbus leidimas buvo „Python 2.7.5“, 2014 m. Pabaigoje. „Python 3“ nepalaikė „IronPython“ - didelis trūkumas, nes „Python 2“ nebebus palaikomas nuo 2020 m., O „Python 3“ yra nustatytas įpėdinis.

Susitikime kūrėjų pokalbių svetainėje „Gitter“, „Earl“, „Eggers“ ir kiti išsiaiškino aktualiausias problemas, su kuriomis susiduria projektas, kai jis eina į priekį: ką daryti su neišspręstomis „IronPython“ problemomis „CodePlex“; kokį išleidimo grafiką įgyvendinti; ir kokį kelio žemėlapį sukurti „IronPython 3“.

Kita diskusijose iškilusi problema buvo tai, kaip įgyvendinti „Python“ bibliotekų, naudojančių C plėtinius, palaikymą. Jei „IronPython“ turi kuo platesnę auditoriją, tai nėra pasirinkimas. Daugelis pagrindinių „Python“ bibliotekų, pvz., „Numpy“, naudoja C plėtinius greičiui pasiekti, ir idealiu atveju jie turėtų veikti taip, kaip yra „IronPython“, nereikalaujant jų kompiliavimo.

Geros naujienos yra tai, kad šioje srityje jau buvo atliktas tam tikras darbas, būtent „Ironclad“ - projektas, sukurtas sudaryti leidimus kompiliuojamiems „CPython“ plėtiniams „IronPython“. Blogos naujienos yra tai, kad projektas seniai nematė daug darbo, todėl jį reikės labai peržiūrėti, kad jis būtų naudingas šiuolaikiniam „Python“.

Iš rubinų ir GIL

Kitas iškilęs klausimas buvo kaip elgtis su panašiu projektu, kurį tvarkė ta pati komanda: „IronRuby“, kuris yra .Net „Ruby“ diegimas, kaip rodo pavadinimas. Abi kalbos buvo sukurtos kartu, nes jos kilo dėl tų pačių „Microsoft“ pastangų dėl „Dynamic Language Runtime“ ir liko visai šalia, kai „Microsoft“ 2010 m. Jas skyrė bendruomenės iniciatyvoms.

Planas yra padaryti „IronRuby“ savo projektą, kad pritrauktų savo kūrėjų auditoriją. „IronPython 2“ taip pat ir toliau bus kuriamas kaip atskiras projektas.

Būsimas „IronPython“ kūrimas gali pasirodyti vaisingas, nes suteikia galimybę įgyvendinti ilgalaikę svajonę apie greitą, daugelio branduolių palaikantį „Python“ vykdymą. „IronPython“ neturi „Global Interpreter Lock“ (GIL) - daugelio „Python“ diegimų ypatybės, kuri buvo kaltinama dėl didelio našumo kliūties.

Tai pasakius, tai, kad „IronPython“ neturi GIL, automatiškai nepadaro jo greitesniu; kai kurie „IronPython“ standartai yra geresni nei „CPython“, tačiau kiti yra žymiai blogesni. Kol kas tiesiog pakelti greitį su „IronPython“ su dabartinėmis „Python“ šakomis, tiek 2, tiek 3, turėtų būti pakankamai misija.

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