Predstavljamo vam tretji del prevoda gradiva o poti, ki jo je opravil Dropbox pri implementaciji sistema za preverjanje tipa za kodo Python.
→ Prejšnji deli: и
Doseganje 4 milijonov vrstic tipkane kode
Drug velik izziv (in druga najpogostejša skrb interno anketiranih) je bilo povečanje količine kode, ki jo pokrivajo preverjanja tipa v Dropboxu. Preizkusili smo več pristopov za rešitev tega problema, od naravnega povečevanja velikosti vnesene kodne baze do osredotočanja prizadevanj ekipe mypy na statično in dinamično avtomatizirano sklepanje o tipih. Na koncu se je zdelo, da preproste zmagovalne strategije ni, vendar nam je s kombiniranjem številnih pristopov uspelo doseči hitro rast obsega označene kode.
Posledično ima naše največje skladišče Python (z zaledno kodo) skoraj 4 milijone vrstic označene kode. Delo na statičnem tipkanju kode je bilo zaključeno v približno treh letih. Mypy zdaj podpira različne vrste poročil o pokritosti kode, ki olajšajo spremljanje napredka tipkanja. Zlasti lahko ustvarimo poročila o kodi z dvoumnostmi v tipih, kot je na primer eksplicitna uporaba tipa Any v opombah, ki jih ni mogoče preveriti, ali s stvarmi, kot je uvoz knjižnic tretjih oseb, ki nimajo opomb vrste. Kot del projekta za izboljšanje natančnosti preverjanja tipov v Dropboxu smo prispevali k izboljšanju definicij tipov (tako imenovanih škrbinskih datotek) za nekatere priljubljene odprtokodne knjižnice v centraliziranem repozitoriju Python .
Implementirali smo (in standardizirali v naslednjih PEP) nove funkcije sistema tipov, ki omogočajo natančnejše tipe za nekatere specifične vzorce Python. Pomemben primer tega je TypeDict, ki zagotavlja tipe za JSON podobne slovarje, ki imajo fiksen nabor nizovnih ključev, od katerih ima vsak vrednost svoje vrste. Še naprej bomo širili tipski sistem. Naš naslednji korak bo verjetno izboljšanje podpore za numerične zmogljivosti Pythona.
Število vrstic označene kode: strežnik
Število vrstic označene kode: odjemalec
Skupno število vrstic označene kode
Tukaj je pregled glavnih značilnosti stvari, ki smo jih naredili za povečanje količine označene kode v Dropboxu:
Strogost pripisov. Postopoma smo stopnjevali zahteve glede strogosti označevanja nove kode. Začeli smo z nasveti za linter, ki so predlagali dodajanje opomb datotekam, ki so že imele nekaj opomb. Zdaj zahtevamo opombe tipa v novih datotekah Python in v večini obstoječih datotek.
Tipkanje poročil. Ekipam pošiljamo tedenska poročila o stopnji vnašanja kode in jim svetujemo, kaj je treba najprej označiti.
Popularizacija mypy. O mypy se pogovarjamo na dogodkih in se pogovarjamo z ekipami, da jim pomagamo začeti z opombami tipov.
Ankete. Izvajamo občasne ankete med uporabniki, da ugotovimo glavne težave. Pri reševanju teh težav smo pripravljeni iti precej daleč (celo ustvariti nov jezik za pospešitev mypy!).
Izvedba. Močno smo izboljšali zmogljivost mypy z uporabo demona in mypyc. To je bilo storjeno, da bi odpravili nevšečnosti, ki nastanejo med postopkom označevanja, in da bi lahko delali z velikimi količinami kode.
Integracija z uredniki. Izdelali smo orodja za podporo izvajanja mypy v urejevalnikih, ki so priljubljeni v Dropboxu. To vključuje PyCharm, Vim in VS Code. To je močno poenostavilo postopek označevanja kode in preverjanje njene funkcionalnosti. Te vrste dejanj so pogoste pri označevanju obstoječe kode.
Statična analiza. Ustvarili smo orodje za sklepanje funkcijskih podpisov z uporabo orodij za statično analizo. To orodje lahko deluje le v sorazmerno preprostih situacijah, vendar nam je pomagalo povečati pokritost vrste kode brez posebnega truda.
Podpora za knjižnice tretjih oseb. Številni naši projekti uporabljajo komplet orodij SQLAlchemy. Izkorišča dinamične zmožnosti Pythona, ki jih vrste PEP 484 ne morejo neposredno modelirati. V skladu s PEP 561 smo ustvarili ustrezno škrbino in napisali vtičnik za mypy (), ki izboljša podporo za SQLAlchemy.
Težave, na katere smo naleteli
Pot do 4 milijonov vrstic tipkane kode za nas ni bila vedno lahka. Na tej poti smo naleteli na veliko lukenj in naredili kar nekaj napak. To je nekaj težav, na katere smo naleteli. Upamo, da bo pripovedovanje o njih drugim pomagalo preprečiti podobne težave.
Manjkajoče datoteke. Delo smo začeli s preverjanjem le majhne količine datotek. Vse, kar ni vključeno v te datoteke, ni bilo preverjeno. Datoteke so bile dodane na seznam za skeniranje, ko so se v njih pojavile prve opombe. Če je bilo nekaj uvoženo iz modula, ki se nahaja zunaj obsega preverjanja, potem smo govorili o delu z vrednostmi, kot je Any, ki sploh niso bili testirani. To je povzročilo znatno izgubo natančnosti tipkanja, zlasti v zgodnjih fazah selitve. Ta pristop je doslej deloval presenetljivo dobro, čeprav je tipična situacija, da dodajanje datotek v obseg pregleda razkrije težave v drugih delih kodne baze. V najslabšem primeru, ko sta bili združeni dve izolirani področji kode, v katerih so bili neodvisno drug od drugega že preverjeni tipi, se je izkazalo, da so tipi teh področij med seboj nekompatibilni. To je povzročilo potrebo po številnih spremembah opomb. Ko zdaj pogledamo nazaj, se zavedamo, da bi morali module osnovne knjižnice dodati v območje preverjanja tipov mypy prej. Tako bi bilo naše delo veliko bolj predvidljivo.
Označevanje stare kode. Ko smo začeli, smo imeli približno 4 milijone vrstic obstoječe kode Python. Jasno je bilo, da označevanje vse te kode ni lahka naloga. Ustvarili smo orodje, imenovano PyAnnotate, ki lahko zbira informacije o vrsti med izvajanjem testov in lahko vaši kodi doda opombe o vrsti na podlagi zbranih informacij. Vendar pa nismo opazili posebej razširjene uporabe tega orodja. Zbiranje informacij o vrsti je bilo počasno in samodejno ustvarjene opombe so pogosto zahtevale veliko ročnih urejanj. Razmišljali smo o samodejnem zagonu tega orodja vsakič, ko pregledamo kodo, ali o zbiranju informacij o vrsti na podlagi analize neke majhne količine dejanskih omrežnih zahtev, vendar smo se odločili, da tega ne bomo storili, ker je bil kateri koli pristop preveč tvegan.
Posledično je mogoče opaziti, da so lastniki večino kode ročno označili. Da bi ta proces usmerili v pravo smer, pripravimo poročila o posebej pomembnih modulih in funkcijah, ki jih je treba označiti. Na primer, pomembno je zagotoviti opombe tipa za knjižnični modul, ki se uporablja na stotinah mest. Toda stara storitev, ki jo zamenjamo z novo, ni več tako pomembna za označevanje. Prav tako eksperimentiramo z uporabo statične analize za ustvarjanje opomb tipa za podedovano kodo.
Ciklični uvozi. Zgoraj sem govoril o cikličnih uvozih (»zapletih odvisnosti«), zaradi katerih je bilo težko pospešiti mypy. Prav tako smo morali trdo delati, da bi mypy podpiral vse vrste idiomov, ki so posledica teh cikličnih uvozov. Nedavno smo zaključili velik projekt prenove sistema, ki je odpravil večino težav mypy v zvezi s krožnimi uvozi. Te težave so pravzaprav izhajale iz zelo zgodnjih dni projekta, od Aloreja, izobraževalnega jezika, na katerega je bil prvotno osredotočen projekt mypy. Sintaksa Alore olajša reševanje težav s cikličnimi ukazi za uvoz. Sodobni mypy je podedoval nekatere omejitve svoje prejšnje, preproste izvedbe (ki je bila zelo primerna za Alore). Python otežuje delo s krožnimi uvozi, predvsem zato, ker so izrazi dvoumni. Na primer, operacija dodelitve lahko dejansko definira vzdevek tipa. Mypy ne more vedno zaznati takšnih stvari, dokler ni obdelana večina uvozne zanke. V Aloreju teh nejasnosti ni bilo. Slabe odločitve v zgodnjih fazah razvoja sistema lahko programerja mnogo let pozneje neprijetno presenetijo.
Rezultati: pot do 5 milijonov vrstic kode in nova obzorja
Projekt mypy je prehodil dolgo pot - od zgodnjih prototipov do sistema, ki nadzoruje 4 milijone vrstic tipov proizvodne kode. Ko se je mypy razvijal, so bili tipski namigi Pythona standardizirani. Te dni se je okoli tipkanja kode Python razvil močan ekosistem. Ima prostor za knjižnično podporo, vsebuje pomožna orodja za IDE in urejevalnike, ima več sistemov za nadzor tipov, od katerih ima vsak svoje prednosti in slabosti.
Čeprav je preverjanje tipa v Dropboxu že samoumevno, verjamem, da smo še vedno v zgodnjih dneh tipkanja kode Python. Mislim, da se bodo tehnologije preverjanja tipa še naprej razvijale in izboljševale.
Če še niste uporabljali preverjanja tipov v svojem obsežnem projektu Python, potem vedite, da je zdaj pravi čas, da začnete prehajati na statično tipkanje. Pogovarjal sem se s tistimi, ki so naredili podoben prehod. Nihče od njih ni obžaloval. Preverjanje tipa naredi Python jezik, ki je veliko bolj primeren za razvoj velikih projektov kot »običajen Python«.
Drage bralke in bralci! Ali v svojih projektih Python uporabljate preverjanje tipa?
Vir: www.habr.com