Vi presenterar för er uppmÀrksamhet den tredje delen av översÀttningen av materialet om vÀgen som Dropbox tog nÀr man implementerade ett typkontrollsystem för Python-kod.
â Tidigare delar: Đž
NĂ€r 4 miljoner rader maskinskriven kod
En annan stor utmaning (och det nÀst vanligaste problemet bland de tillfrÄgade internt) var att öka mÀngden kod som omfattas av typkontroller i Dropbox. Vi har prövat flera tillvÀgagÄngssÀtt för att lösa detta problem, frÄn att naturligt öka storleken pÄ den maskinskrivna kodbasen till att fokusera mypy-teamets anstrÀngningar pÄ statisk och dynamisk automatiserad typinferens. Till slut verkade det som om det inte fanns nÄgon enkel vinnande strategi, men vi kunde uppnÄ snabb tillvÀxt i volymen av kommenterad kod genom att kombinera mÄnga tillvÀgagÄngssÀtt.
Som ett resultat har vÄrt största Python-förrÄd (med backend-kod) nÀstan 4 miljoner rader med kommenterad kod. Arbetet med statisk kodskrivning avslutades pÄ cirka tre Är. Mypy stöder nu olika typer av kodtÀckningsrapporter som gör det enklare att övervaka skrivframsteg. I synnerhet kan vi generera rapporter om kod med oklarheter i typer, som till exempel explicit anvÀndning av en typ Any i annoteringar som inte kan verifieras, eller med saker som att importera tredjepartsbibliotek som inte har typkommentarer. Som en del av ett projekt för att förbÀttra noggrannheten för typkontroll i Dropbox, bidrog vi till att förbÀttra typdefinitionerna (sÄ kallade stubbfiler) för nÄgra populÀra bibliotek med öppen kÀllkod i ett centraliserat Python-förrÄd .
Vi implementerade (och standardiserade i efterföljande PEP) nya funktioner i typsystemet som tillÄter mer exakta typer för vissa specifika Python-mönster. Ett anmÀrkningsvÀrt exempel pÄ detta Àr TypeDict, som tillhandahÄller typer för JSON-liknande ordböcker som har en fast uppsÀttning strÀngnycklar, var och en med ett vÀrde av sin egen typ. Vi kommer att fortsÀtta bygga ut typsystemet. VÄrt nÀsta steg blir sannolikt att förbÀttra stödet för Pythons numeriska kapacitet.
Antal rader med kommenterad kod: server
Antal rader med kommenterad kod: klient
Totalt antal rader med kommenterad kod
HÀr Àr en översikt över huvuddragen för de saker vi gjorde för att öka mÀngden kommenterad kod i Dropbox:
AnteckningsstrÀnghet. Vi ökade gradvis kraven pÄ noggrannheten med att kommentera ny kod. Vi började med linter-tips som föreslog att du skulle lÀgga till kommentarer till filer som redan hade nÄgra kommentarer. Vi krÀver nu typkommentarer i nya Python-filer och i de flesta befintliga filer.
Skriva rapporter. Vi skickar team veckovisa rapporter om nivÄn pÄ att skriva in sin kod och ger rÄd om vad som bör kommenteras först.
Popularisering av mypy. Vi pratar om mypy vid evenemang och pratar med team för att hjÀlpa dem komma igÄng med typkommentarer.
Omröstningar. Vi genomför periodiska anvÀndarundersökningar för att identifiera stora problem. Vi Àr redo att gÄ ganska lÄngt för att lösa dessa problem (Àven skapa ett nytt sprÄk för att pÄskynda mypy!).
Prestanda. Vi har avsevÀrt förbÀttrat prestandan för mypy genom att anvÀnda demonen och mypyc. Detta gjordes för att jÀmna ut de olÀgenheter som uppstÄr under anteckningsprocessen, och för att kunna arbeta med stora mÀngder kod.
Integration med redaktörer. Vi har byggt verktyg för att köra mypy i redigerare som Àr populÀra pÄ Dropbox. Detta inkluderar PyCharm, Vim och VS Code. Detta förenklade avsevÀrt processen att kommentera koden och kontrollera dess funktionalitet. Dessa typer av ÄtgÀrder Àr vanliga nÀr man kommenterar befintlig kod.
Statisk analys. Vi skapade ett verktyg för att hÀrleda funktionssignaturer med hjÀlp av statiska analysverktyg. Det hÀr verktyget kan bara fungera i relativt enkla situationer, men det hjÀlpte oss att öka vÄr kodtypstÀckning utan större anstrÀngning.
Stöd för tredje parts bibliotek. MÄnga av vÄra projekt anvÀnder verktygslÄdan SQLAlchemy. Den drar fördel av de dynamiska funktionerna hos Python som PEP 484-typer inte kan modellera direkt. Vi, i enlighet med PEP 561, skapade motsvarande stubfil och skrev ett plugin för mypy (), vilket förbÀttrar SQLAlchemy-stödet.
SvÄrigheter vi stötte pÄ
VÀgen till 4 miljoner rader med maskinskriven kod har inte alltid varit lÀtt för oss. PÄ den hÀr stigen stötte vi pÄ mÄnga gropar och gjorde flera misstag. Det hÀr Àr nÄgra av de problem vi stötte pÄ. Vi hoppas att berÀtta om dem hjÀlper andra att undvika liknande problem.
Saknade filer. Vi började vÄrt arbete med att bara kontrollera en liten mÀngd filer. Allt som inte ingick i dessa filer kontrollerades inte. Filer lades till i skanningslistan nÀr de första anteckningarna dök upp i dem. Om nÄgot importerades frÄn en modul som ligger utanför verifieringsomfÄnget, pratade vi om att arbeta med vÀrden som Any, som inte testades alls. Detta ledde till en betydande förlust av skrivnoggrannhet, sÀrskilt i de tidiga stadierna av migration. Detta tillvÀgagÄngssÀtt har fungerat förvÄnansvÀrt bra hittills, Àven om en typisk situation Àr att lÀgga till filer i granskningens omfattning avslöjar problem i andra delar av kodbasen. I vÀrsta fall, nÀr tvÄ isolerade kodomrÄden slogs samman, dÀr, oberoende av varandra, typer redan var kontrollerade, visade det sig att typerna av dessa omrÄden var inkompatibla med varandra. Detta ledde till behovet av att göra mÄnga Àndringar i anteckningarna. NÀr vi ser tillbaka nu inser vi att vi borde ha lagt till kÀrnbiblioteksmoduler till mypys typkontrollomrÄde tidigare. Detta skulle göra vÄrt arbete mycket mer förutsÀgbart.
Kommentera gammal kod. NÀr vi började hade vi cirka 4 miljoner rader med befintlig Python-kod. Det var tydligt att det inte var en lÀtt uppgift att kommentera all denna kod. Vi har skapat ett verktyg som heter PyAnnotate som kan samla in typinformation nÀr tester körs och kan lÀgga till typkommentarer till din kod baserat pÄ den insamlade informationen. Vi har dock inte mÀrkt en sÀrskilt utbredd anvÀndning av detta verktyg. Insamling av typinformation gick lÄngsamt och automatiskt genererade anteckningar krÀvde ofta mÄnga manuella redigeringar. Vi funderade pÄ att köra det hÀr verktyget automatiskt varje gÄng vi granskar kod, eller pÄ att samla in typinformation baserat pÄ analys av en liten volym av faktiska nÀtverksförfrÄgningar, men beslutade att inte göra det eftersom bÄda tillvÀgagÄngssÀtten var för riskabla.
Som ett resultat kan det noteras att det mesta av koden antecknades manuellt av dess Àgare. För att styra denna process i rÀtt riktning utarbetar vi rapporter om sÀrskilt viktiga moduler och funktioner som behöver kommenteras. Till exempel Àr det viktigt att tillhandahÄlla typkommentarer för en biblioteksmodul som anvÀnds pÄ hundratals platser. Men en gammal tjÀnst som byts ut mot en ny Àr inte lÀngre sÄ viktig att kommentera. Vi experimenterar ocksÄ med att anvÀnda statisk analys för att generera typkommentarer för Àldre kod.
Cyklisk import. Ovan pratade jag om cykliska importer (âberoendehĂ€rvornaâ), vars existens gjorde det svĂ„rt att pĂ„skynda mypy. Vi var ocksĂ„ tvungna att arbeta hĂ„rt för att fĂ„ mypy att stödja alla typer av idiom som orsakas av dessa cykliska importer. Vi har nyligen slutfört ett stort systemomformningsprojekt som fixade de flesta av mypys problem angĂ„ende cirkulĂ€r import. Dessa problem hĂ€rrörde faktiskt frĂ„n de allra första dagarna av projektet, tillbaka frĂ„n Alore, det pedagogiska sprĂ„ket som mypy-projektet ursprungligen var fokuserat pĂ„. Alore-syntax gör det enkelt att lösa problem med cykliska importkommandon. Modern mypy har Ă€rvt nĂ„gra begrĂ€nsningar frĂ„n dess tidigare enkla implementering (som passade utmĂ€rkt för Alore). Python gör det svĂ„rt att arbeta med cirkulĂ€r import, frĂ€mst för att uttrycken Ă€r tvetydiga. Till exempel kan en tilldelningsoperation faktiskt definiera ett typalias. Mypy kan inte alltid upptĂ€cka sĂ„dant hĂ€r förrĂ€n det mesta av importslingan har bearbetats. Det fanns inga sĂ„dana oklarheter i Alore. DĂ„liga beslut som fattas i de tidiga stadierna av systemutveckling kan innebĂ€ra en obehaglig överraskning för programmeraren mĂ„nga Ă„r senare.
Resultat: vÀgen till 5 miljoner rader kod och nya horisonter
Mypy-projektet har kommit lÄngt - frÄn tidiga prototyper till ett system som kontrollerar 4 miljoner rader av produktionskodtyper. Allt eftersom mypy utvecklades standardiserades Pythons typtips. Dessa dagar har ett kraftfullt ekosystem utvecklats kring att skriva Python-kod. Den har en plats för biblioteksstöd, den innehÄller extraverktyg för IDE:er och redaktörer, den har flera typkontrollsystem, som vart och ett har sina egna för- och nackdelar.
Ăven om typkontroll redan Ă€r givet pĂ„ Dropbox, tror jag att vi fortfarande Ă€r i början av att skriva Python-kod. Jag tror att typkontrolltekniker kommer att fortsĂ€tta att utvecklas och förbĂ€ttras.
Om du inte redan har anvÀnt typkontroll i ditt storskaliga Python-projekt, vet att det nu Àr en mycket bra tid att börja gÄ över till statisk typning. Jag har pratat med dem som har gjort en liknande övergÄng. Ingen av dem Ängrade sig. Typkontroll gör Python till ett sprÄk som Àr mycket bÀttre lÀmpat för att utveckla stora projekt Àn "vanlig Python".
KÀra lÀsare! AnvÀnder du typkontroll i dina Python-projekt?
KĂ€lla: will.com
