Pythoni tüübikontrolli võrdlus: tühja konteineri järeldus

Miks tühjad konteinerid rikuvad Pythoni tüübikontrolli – ja mida saate sellega teha?

Pythoni järkjärguline tippimise süsteem on märkimisväärselt arenenud pärast seda, kui PEP 484 tutvustas 2015. aastal tüübivihjeid. Tänapäeval toetuvad miljonid arendajad staatilisele tüübikontrollile, et tuvastada vead enne, kui need tootmisse jõuavad. Kuid tüübisüsteemis on üks peen ja masendav nurk, mis komistab isegi kogenud insenere: mis tüüpi on tühi konteiner? Kui kirjutate x = [] ilma märkusteta, peab teie tüübikontrollija ära arvama – ja erinevad kontrollijad arvavad erinevalt. See lahknevus tekitab suuri koodibaase haldavatele meeskondadele tõsiseid probleeme, kus tüübikontrollide vahetamine või kombineerimine võib üleöö esile tuua sadu ootamatuid vigu.

Selles artiklis kirjeldatakse, kuidas neli peamist Pythoni tüüpi kontrollijat – mypy, pyright, pytype ja pyre – käsitlevad tühja konteineri järeldusi, miks nad ei nõustu ja milliseid praktilisi strateegiaid saate kasutada tüübikindla Pythoni kirjutamiseks olenemata tööriistavalikust.

Põhiprobleem: tühjad konteinerid on oma olemuselt mitmetähenduslikud

Kaaluge seda kahjutut Pythoni rida: results = []. Kas tulemused on loend[int]? loend[str]? Kas loend[dict[str, Any]]? Ilma täiendava kontekstita pole tegelikult mingit võimalust teada. Pythoni käitusaeg ei hooli – loendid on oma olemuselt heterogeensed –, kuid staatilise tüübi kontrollijad peavad oma töö tegemiseks määrama igale muutujale konkreetse tüübi. See loob põhimõttelise pinge Pythoni dünaamilise paindlikkuse ja garantiide vahel, mida staatiline analüüs püüab pakkuda.

Probleemiühendid sõnastike ja komplektidega. Tühi {} sõelutakse tegelikult diktina, mitte komplektina, mis lisab tüübitasandi mitmetähenduslikkusele lisaks süntaktilist mitmetähenduslikkust. Ja pesastatud konteinerid – mõelge defaultdict(list) või results = {k: [] võtmetes k – viivad järeldusmootorid oma piiridesse. Igal tüübikontrollil on välja töötatud oma heuristika ja erinevused on olulisemad, kui enamik arendajaid mõistab.

Tootmissüsteemides, mis töötlevad tegelikku töökoormust – olgu selleks siis kliendikirjeid käsitlev CRM, reaüksusi genereeriv arveldusmoodul või mõõdikuid koondav analüütikakonveier –, ilmuvad tühjad konteinerid pidevalt lähtestamismustritena. Nende tüüpide eksimine ei too kaasa mitte ainult põikhoiatusi; see võib varjata tõelisi vigu, mis libisevad käitusajale.

Mypy: edasilükatud järeldused kaudse ükskõik millisega

Mypy, vanim ja laialdasemalt kasutusele võetud Pythoni tüüpi kontrollija, suhtub tühjadesse konteineritesse suhteliselt leebelt. Kui see kohtab funktsiooni ulatuses x = [], proovib see tüübiotsust edasi lükata ja järeldada elemendi tüübi hilisemast kasutamisest. Kui kirjutate x = [], millele järgneb x.append(42), järeldab mypy list[int]. See "liitumise" strateegia töötab üllatavalt hästi lihtsate juhtumite puhul, kus konteiner on täidetud samas ulatuses.

Kuid mypy käitumine muutub dramaatiliselt sõltuvalt kontekstist ja ranguse seadetest. Mooduli ulatuse korral (ülataseme kood) või kui konteiner edastatakse enne täitmist mõnele teisele funktsioonile, langeb mypy sageli tagasi loendisse[Igasugune]. Lipu ---range all käivitab see vea, kuid vaikerežiimis möödub see vaikselt. See tähendab, et meeskonnad, kes käitavad mypyt ilma range režiimita, võivad koguda kümneid kaudselt sisestatud konteinereid, mis toimivad tüübisüsteemist pääsemise luukidena, rikkudes selle eesmärgi.

Üks eriti peen käitumine: mypy versioonid, mis on vanemad kui 0.990, järeldasid mõnikord sisemiselt loendi loend[Unknown] ja laienevad seejärel määramisel loendile loend[Igasugune]. Pärast 0.990 järeldust karmistati, kuid muudatus purustas üllatavalt palju reaalse maailma koodibaase, mis olid lootnud lubavale käitumisele, ilma et oleks sellest aru saanud. See on korduv teema – tühja konteineri järelduse muudatused on ühed kõige häirivamad tüübikontrolli värskendused, kuna mustrid on nii üldlevinud.

Pügiõigus: range järeldus ja "tundmatu" tüüp

Pyright, mille on välja töötanud Microsoft ja mis toidab Pylance'i VS Code'is, võtab põhimõtteliselt teistsuguse filosoofilise seisukoha. Selle asemel, et vaikselt minna tagasi valikule Igasugune, eristab autoriõigus Tundmatut (tüüp, mis pole veel kindlaks määratud) ja Igasugune (selgesõnaline tüübikontrollist loobumine). Kui kirjutate autoriõiguse ranges režiimis x = [], järeldab see loend[Tundmatu] ja teatab diagnostikast, sundides teid märkuse esitama.

Püriõigus suhtub agressiivsemalt ka ulatusala ahenemisse. Kui kirjutate:

• x = [], millele järgneb x.append("tere") – autoriõigus järeldab loendi[str]
• x = [], millele järgneb x.append(1) ja seejärel x.append("tere") – autoriõiguse alusel järeldub loend[int | str]
• x = [] edastati otse funktsioonile, mis eeldab loendit[int] – autoriõigus järeldab list[int] kõne saidi kontekstist
• x = [] tagastati funktsioonist ilma tagastustüübi märkuseta – autoriõigus teatab pigem veast kui arvab

See kahesuunaline järeldus (kasutades nii hilisemat kasutust kui ka kõnesaitidelt oodatavaid tüüpe) muudab tühjade konteinerite puhul autoriõiguse märkimisväärselt täpsemaks kui mypy. Kompromiss on paljusõnalisus: mitmete avatud lähtekoodiga migratsiooniaruannete analüüsi kohaselt märgib autoriõiguse range režiim tüüpilisel märkusteta koodibaasil ligikaudu 30–40% rohkem probleeme, võrreldes mypy range režiimiga. Meeskondade jaoks, kes ehitavad keerulisi taustasüsteeme – näiteks platvormi, mis haldab 207 omavahel ühendatud moodulit, mis hõlmavad CRM-i, palgaarvestust ja analüütikat –, tuvastab autoriõiguse range liidese peened ebakõlad, mida leebed järeldused eiraks.

Pytype ja Pyre: vähem läbitud teed

Google'i pytype kasutab võib-olla kõige pragmaatilisemat lähenemist. Selle asemel, et nõuda märkusi või minna tagasi valikule Igasugune, kasutab pytype kogu programmi analüüsi, et jälgida konteineri kasutamist üle funktsioonide piiride. Kui loote ühes funktsioonis tühja loendi ja edastate selle teisele, mis lisab täisarvud, võib pytype sageli järeldada list[int] ilma igasuguste märkusteta. See funktsioonidevaheline järeldus on arvutuslikult kulukas – pytype on suurte koodibaaside puhul oluliselt aeglasem kui mypy või pyright –, kuid annab märkusteta koodi puhul vähem valepositiivseid tulemusi.

Pytype tutvustab tühjade konteinerite jaoks ka mõistet "osalised tüübid". Värskelt loodud [] saab osalise tüübi, mida täiustatakse järk-järgult, kui kontrollijat kasutatakse rohkem. See on kontseptuaalselt elegantne, kuid võib tekitada segadust tekitavaid veateateid, kui osalist tüüpi ei saa täielikult lahendada, näiteks kui tühi konteiner liigub läbi mitme funktsiooni, ilma et see oleks kunagi täidetud.

Meta pirakas läheneb samal ajal mypy käitumisele, kuid rangemate vaikeväärtustega. Pyre käsitleb x = [] kui loendit[tundmatu] ja nõuab enamikus kontekstides annoteerimist. Pyre eristab end kwargidena kasutatavate tühjade sõnastikuliteraalide käsitlemises – see on veebiraamistikes levinud muster. Pyre'il on erijuhtude loogika, mis võimaldab järeldada märksõnaargumentide kontekstidest sõnastiku tüüpe, vähendades annotatsioonikoormust raamistikku rasketes koodibaasides. Arvestades, et enamikus kaasaegsetes veebirakendustes kasutatakse konfigureerimiseks ja taotluste käsitlemiseks palju sõnastiku lahtipakkimist, tasub see pragmaatilisus kasu.

Mõju tegelikule maailmale: kui järeldused lahknevad

Tüübikontrollide erinevused võivad tunduda akadeemilised, kuni neid tootmiskoodibaasis kogete. Mõelge ärirakendustes levinud mustrile: tingimuslikult asustatud andmestruktuuri lähtestamine.

Kõige ohtlikumad tühjad konteinerid ei ole need, millel on märgistuslipp – need lähevad vaikselt läbi koos tuletatud mis tahes tüübiga, võimaldades ühildumatutel andmetel ilma hoiatuseta koguneda, kuni allavoolu funktsioon jookseb kokku Tüübivea tõttu, mille päritolu on peaaegu võimatu tuvastada.

Konkreetne näide: fintechi idufirma meeskond teatas, et kulutas kolm päeva tootmisprobleemi silumisele, kus maksetöötlusfunktsioonis lähtestatud tühja loendi järeldas mypy kui loend[Any]. Loend pidi sisaldama valuutasummade kümnendkoha objekte, kuid kooditee lisab selle asemel ujuvad väärtused. Mypy leebe järeldus lubas seda vaikselt. Viga ilmnes alles siis, kui ujukaritmeetika ümardamisvead põhjustasid 0,01 dollari suuruse lahknevuse 12 000 arve partii puhul. Kui nad oleks kasutanud autoriõigust ranges režiimis või oleks lihtsalt tühja loendi märkinud kui loend[Decimal], oleks viga arenduse ajal tabatud.

Mewayzis, kus platvorm töötleb arveid, palgaarvestusi ja finantsanalüütikat 138 000+ kasutajakontol, ei ole selline tüübiohutuse lünk teoreetiline – see on erinevus õigete palgaarvestuste ja kulukate ümberarvutuste vahel. Konteinerite initsialiseerimisega seotud range tippimisdistsipliin on üks neist "igavatest" inseneritavadest, mis hoiab ära põnevad tootmisintsidendid.

Kaitsekonteinerite initsialiseerimise parimad tavad

Sõltumata sellest, millist tüüpi kontrollijat teie meeskond kasutab, on tühja konteineri ebaselguse täielikuks kõrvaldamiseks olemas konkreetsed strateegiad. Eesmärk on mitte kunagi tugineda tühjade konteinerite puhul järeldustele – muutke tüüp selgesõnaliseks, nii et teie kood oleks kõigi kontrollijate jaoks kaasaskantav ja immuunne järelduste käitumise muutuste suhtes versioonide vahel.

1. Märkige alati tühjad konteineri muutujad. Kirjutage results = [] asemel results: list[int] = []. Väiksed paljusõnalised kulud on tühised, võrreldes säästetud silumisajaga. See üksainus tava kõrvaldab ligikaudu 80% tühja konteineri järelduste probleemidest.
2. Kasutage keeruliste konteinerite jaoks tehasefunktsioone. Sisestage cache = {} asemel funktsioon nagu def make_cache() -> dict[str, list[UserRecord]]: return {}. Tagastustüübi märkus muudab soovitud tüübi üheselt mõistetavaks ja isedokumenteeruvaks.
3. Eelistage mittetriviaalsete tüüpide puhul trükitud konstruktoreid literaalidele. Kirjutage üksused: set[int] = set(), selle asemel, et tugineda hulga mõistmise järeldusele. Sisestage defaultdict ja Counter puhul alati tüübiparameeter: counts: Counter[str] = Counter().
4. Seadistage oma tüübikontrolli range režiim uue koodi jaoks. Nii mypy kui ka pyright toetavad faili või kataloogi konfiguratsiooni. Lubage uute moodulite range kontrollimine pärandkoodi järkjärgulise üleviimise ajal. See hoiab ära uute kaudselt trükitud konteinerite kogunemise.
5. Lisage oma CI-konveierile tüübikontrolli võrdlus. Nii mypy kui ka pyrighti käivitamine koodibaasis tuvastab varakult järelduste erinevuse. Kui muster läbib ühe kontrolli, kuid ebaõnnestub teises, on see signaal, et tüüp ei ole piisavalt selge.

Suurem pilt: tüübikontroll kui meeskonnapraktika

Tühja konteineri järeldus on lõpuks Pythoni tüüpi süsteemi suurema väljakutse mikrokosmos: pinge mugavuse ja ohutuse vahel. Pythoni filosoofia "me kõik oleme nõus täiskasvanud" töötab prototüüpide ja skriptide puhul suurepäraselt, kuid tuhandeid kasutajaid teenindavad tootmissüsteemid vajavad tugevamaid tagatisi. Asjaolu, et neli peamist tüübikontrollijat ei nõustu millegi nii lihtsa kui [] tüübi osas, rõhutab, et Pythoni tippimisökosüsteem on alles küpsemas.

Keerulisi platvorme ehitavatele insenerimeeskondadele – olenemata sellest, kas haldate käputäis mikroteenuseid või sadade omavahel ühendatud moodulitega integreeritud süsteemi (nt Mewayzi äriOS) – on praktiline nõuanne otsekohene: ärge tuginege tühjade konteinerite järeldamisele, valige tüübikontroll ja konfigureerige see rangelt ning käsitlege tüübimärkusi kui masinkontrollitavat dokumentatsiooni. Viis minutit, mis kulub loendi[arve] kirjutamisele [] asemel, säästab teid koodibaasi skaleerimisel tunde silumisest.

Kuna PEP 696 (vaikimisi tüübiparameetrid) ja PEP 695 (tüübiparameetrite süntaks) jõuavad jätkuvalt Pythoni uuematesse versioonidesse, paraneb selgesõnalise tippimise ergonoomika pidevalt. Lõhe "märkusteta" ja "märkusteta" Pythoni vahel väheneb. Kuid kuni selle päevani on selgesõnalised konteineritüübid jäänud Pythoni arendaja tööriistakomplekti üheks kõrgeima ROI-ga praktikaks – väikeseks distsipliiniks, mis maksab liitintressi iga mooduli, iga sprindi ja iga tootmisjuurutuse eest.

Korduma kippuvad küsimused

Miks ei suuda tüübikontrollid tühja loendi tüübi osas kokku leppida?

Kui kirjutate "x = []", peab tüübikontroll tuletama tüübi ilma selgete vihjeteta. Erinevad kontrollijad kasutavad erinevaid strateegiaid: mõned järeldavad loendist [ükskõik milline] (loend kõigest), samas kui teised võivad järeldada täpsemat, kuid ebaõiget tüüpi, näiteks "loend[puudub]". See universaalse standardi puudumine on põhjus, miks nad ei nõustu. Mitut kabe kasutavate projektide puhul võib see ebakõla tekitada suurt peavalu, rikkudes analüüsi ühes tööriistas, mis läheb läbi teises.

Milline on lihtsaim viis tühja konteineri vigade parandamiseks?

Kõige lihtsam lahendus on esitada selgesõnaline tüübimärkus. Otsi „minu_loend = []” asemel kirjutage soovitud tüübi selgesõnaliseks deklareerimiseks „minu_loend: list[str] = []”. See eemaldab tüübikontrollist igasuguse ebaselguse, tagades järjepideva käitumise erinevate tööriistade (nt mypy, Pyright ja Pyre) puhul. Seda tava on soovitatav kasutada kõigi tühja konteineri lähtestamise korral, et vältida järeldusvigu.

Kuidas käsitleda tühje konteinereid klassimääratlustes?

See on tavaline probleem, kuna klasside sees olevad märkused nõuavad erilist käsitlemist. Kui loend on mõeldud klassi atribuudiks, peate kasutama importimist „from __future__ import annotations” või „ClassVar” märkust. Näiteks `klass MyClass: minu_loend: ClassVar[loend[str]] = []`. Ilma selleta võib tüübikontrollil olla raskusi tüübi õige järeldamisega, mis toob kaasa vigu.

Kas on olemas tööriistu, mis aitavad suurtes projektides neid tippimisprobleeme hallata?

Jah, täiustatud tüübikontrollid, nagu Pyright (mis annab VS-koodis Pylance'ile volitused), on eriti head keerukate järelduste käsitlemisel. Suurte koodibaaside puhul võivad sellised platvormid nagu Mewayz (pakkudes 207 analüüsimoodulit hinnaga 19 dollarit kuus) pakkuda sügavamat ja järjepidevamat tüübikontrolli ning aidata kogu teie meeskonnas annotatsiooni tavasid jõustada, leevendades artiklis käsitletud ebakõlasid.