Python motako egiaztatzaileen konparaketa: edukiontzi hutsaren inferentzia

Ontzi hutsek zergatik hausten duten Python motako zuzentzaileak — eta zer egin dezakezu horri buruz

Python-en pixkanakako idazketa-sistema nabarmen hazi da PEP 484-k 2015ean mota-aholkuak sartu zituenetik. Gaur egun, milioika garatzailek motaren egiaztatzaile estatikoetan oinarritzen dira akatsak harrapatzeko produkziora iritsi aurretik. Baina bada mota-sistemaren txoko sotil eta frustragarri bat, oraindik ere esperientziadun ingeniariak ere ibiltzen dituena: zer mota du edukiontzi huts batek? x = [] oharrik gabe idazten duzunean, zure mota-zuzentzaileak asmatu behar du, eta zuzentzaile ezberdinek desberdin asmatzen dute. Dibergentzia honek benetako arazoak sortzen ditu kode-oinarri handiak mantentzen dituzten taldeentzat, non mota-zuzentzaileak aldatzeak edo konbinatzeak ustekabeko ehunka akats azalera ditzake egun batetik bestera.

Artikulu honek Python motako lau egiaztatzaile nagusiek (mypy, pyright, pytype eta pyre) edukiontzi hutsen inferentzia nola kudeatzen duten azaltzen du, zergatik ez dauden ados eta zein estrategia praktiko har ditzakezun mota segurua den Python idazteko, tresnaren aukera edozein dela ere.

Oinarrizko arazoa: ontzi hutsak berez anbiguoak dira

Kontuan izan Python-en lerro inozo hau: emaitzak = []. emaitzak zerrenda[int] al dira? zerrenda[str]? Zerrenda bat[dik[str, Edozein]]? Testuinguru gehigarririk gabe, ez dago benetan jakiteko modurik. Python-en exekuzio-denborak ez du axola —zerrendak heterogeneoak dira berez—, baina motako zuzentzaile estatikoek mota konkretu bat esleitu behar diote aldagai bakoitzari beren lana egiteko. Horrek oinarrizko tentsioa sortzen du Python-en malgutasun dinamikoaren eta analisi estatikoak ematen saiatzen diren bermeen artean.

Arazoa hiztegiekin eta multzoekin konposatzen da. {} huts bat dikta gisa analizatzen da, ez multzo gisa, eta horrek anbiguotasun sintaktikoa gehitzen du mota-mailako anbiguotasunari. Eta habiaraturiko edukiontziak — pentsa defaultdict(zerrenda) edo results = {k: [] for k teklatan - inferentzia motorrak beren mugetara bultzatzen dituzte. Mota egiaztatzaile bakoitzak bere heuristika garatu du, eta desberdintasunak garatzaile gehienek uste dutena baino esanguratsuagoak dira.

Benetako lan-kargak prozesatzen dituzten produkzio-sistemetan (bezeroen erregistroak kudeatzen dituen CRM bat, lerro-elementuak sortzen dituen fakturazio-modulu bat edo analisi-bideen batuketa-neurriak) edukiontzi hutsak etengabe agertzen dira hasierako eredu gisa. Haien motak gaizki hartzeak ez du linter abisuak soilik sortzen; exekuzio garaira igarotzen diren benetako akatsak ezkuta ditzake.

Mypy: Inferentzia geroratua edozein inplizituarekin

Mypy-k, Python motako egiaztatzailerik zaharrena eta erabiliena, ontzi hutsen ikuspegi nahiko leuna hartzen du. Funtzio-esparruan x = [] aurkitzen duenean, motaren erabakia atzeratzen eta elementu-mota ondorengo erabileratik ondorioztatzen saiatzen da. x = [] eta ondoren x.append(42) idazten baduzu, mypy-k list[int] ondorioztatuko du. "Batu" estrategia honek harrigarriro ondo funtzionatzen du edukiontzia esparru berean beteta dagoen kasu zuzenetarako.

Hala ere, mypy-ren portaera izugarri aldatzen da testuinguruaren eta zorroztasun-ezarpenen arabera. Moduluaren esparruan (goi-mailako kodea), edo edukiontzia bete aurretik beste funtzio batera pasatzen denean, mypy maiz zerrenda[Edozein]era itzultzen da. --strict markapean, honek errore bat abiarazten du, baina modu lehenetsian isilean pasatzen da. Horrek esan nahi du modu zorrotzik gabe mypy exekutatzen duten taldeek inplizituki idatzitako dozenaka ontzi pila ditzaketela mota-sistematik ihes-estotila gisa jarduten dutenak, bere helburua gaindituz.

Jokaera bereziki sotil bat: 0.990 baino lehenagoko mypy bertsioek batzuetan zerrenda[Ezezaguna] barnetik ondorioztatuko lukete eta gero zerrenda[Edozein]era zabalduko dute esleipenean. 0.990 osteko, inferentzia zorroztu egin zen, baina aldaketak mundu errealeko kode-oinarri harrigarri bat hautsi zuen, konturatu gabe jokabide permisiboan oinarritzen zirenak. Hau errepikatzen den gaia da: edukiontzi hutsaren inferentziaren aldaketak mota-zuzentzaileen eguneratzerik kaltegarrienetakoak dira, ereduak oso nonahikoak direlako.

Pyright: Inferentzia zorrotza eta "Ezezaguna" mota

Pyright-ek, Microsoft-ek garatua eta Pylance VS Code-n bultzatzen duena, jarrera filosofiko oso desberdina hartzen du. Isilik Edonorra itzuli beharrean, pyright-ek Ezezaguna (oraindik zehaztu ez den mota) eta Edozein (mota egiaztatzeko aukera esplizituki ezabatu) bereizten ditu. Pyright-en modu zorrotzean x = [] idazten duzunean, zerrenda[Ezezaguna] ondorioztatzen du eta diagnostiko baten berri ematen du, ohar bat ematera behartuz.

Pyright ere oldarkorragoa da esparrua murrizteari buruz. Idazten baduzu:

• x = [] eta ondoren x.append("kaixo") - pyright-ek zerrenda[str]
ondorioztatzen du
• x = [] ondoren x.append(1) eta gero x.append("kaixo") — pyright-ek zerrenda[int | str
• x = [] zuzenean list[int] espero duen funtzio batera pasatu da — pyright-ek list[int] dei-gunearen testuingurutik ondorioztatzen du
• x = [] itzulera motako oharpenik gabeko funtzio batetik itzuli da — pyright-ek errore baten berri ematen du asmatzea baino

Norabide biko inferentzia honek (ondorengo erabilera eta dei-guneetatik espero diren motak erabiliz) pyright-a mypy baino zehatzagoa da ontzi hutsetarako. Konpromisoa verbositatea da: pyright-en modu zorrotzak gutxi gorabehera %30-40-a arazo gehiago markatzen ditu oharrik gabeko kode-oinarri tipiko batean mypy-ren modu zorrotzarekin alderatuta, kode irekiko migrazio-txosten batzuen analisien arabera. Backend sistema konplexuak eraikitzen dituzten taldeentzat —esan, CRM, nominak eta analisiak barne hartzen dituen interkonektatutako 207 modulu kudeatzen dituen plataforma bat— pyright-en zorroztasunak inferentzia aringarriak galduko lituzkeen interfaze-desegokitasun sotilak harrapatzen ditu.

Pytype eta Pyre: Gutxien Ibiltzen diren Errepideak

Google-ren pytype-k ikuspegi pragmatikoena hartzen du agian. Oharpenak eskatu edo Edozeinera itzuli beharrean, pytype-k programa osoko analisia erabiltzen du edukiontzi bat funtzio-mugetan zehar nola erabiltzen den jarraitzeko. Funtzio batean zerrenda huts bat sortzen baduzu eta osoak gehitzen dituen beste bati pasatzen bazaio, pytype-k askotan list[int] ondorioztatu dezake inolako oharrik gabe. Funtzio gurutzatuko inferentzia hau konputazionalki garestia da — pytype mypy edo pyright baino nabarmen motelagoa da kode-oinarri handietan — baina positibo faltsu gutxiago sortzen ditu oharrik gabeko kodean.

Pytypek "mota partzialak" kontzeptua ere aurkezten du edukiontzi hutsetarako. Sortu berri den [] mota partzial bat lortzen da, eta pixkanaka hobetzen den egiaztatzaileak erabilera gehiago aurkitzen duen heinean. Hau kontzeptuz dotorea da, baina errore-mezu nahasgarriak sor ditzake mota partziala guztiz konpondu ezin denean, esate baterako, edukiontzi huts batek hainbat funtzio igarotzen dituenean inoiz bete gabe.

Meta-ren piroa, berriz, mypyren portaeratik hurbilago dago baina lehenespen zorrotzagoekin. Pyre-k x = [] zerrenda[ezezaguna] gisa tratatzen du eta oharrak eskatzen ditu testuinguru gehienetan. Pyre-k bere burua bereizten duen kvarg gisa erabiltzen diren hiztegi hutsakren erabileran da — web esparruetan ohikoa den eredua. Pyre-k kasu bereziko logika du hiztegi-motak gako-argumentu-testuinguruetatik ondorioztatzeko, marko-astuneko kode-oinarrietan oharpen-zama murriztuz. Web-aplikazio moderno gehienek hiztegia desegitearen erabilera handia dakartela konfiguraziorako eta eskaerak kudeatzeko, pragmatismo honek fruituak ematen ditu.

Mundu errealeko eragina: inferentzia dibergentzia hozka egiten denean

Mota-zuzentzaileen arteko desberdintasunak akademikoak dirudite produkzio-kode-base batean bizi arte. Demagun negozio-aplikazioetan ohiko eredu bat: baldintzapean betetzen den datu-egitura bat hasieratzea.