Vägen till typkontroll av 4 miljoner rader Python-kod. Del 3

Vi presenterar tredje delen av översättningen av materialet om den resa som Dropbox har genomgått för att införa ett system för typkontroll av Python-kod.

→ Tidigare delar: första och två

Att nå 4 miljoner rader typad kod

En annan viktig uppgift (detta var det näst mest populära problemet som oroade dem som deltog i interna enkäter) var att öka mängden kod i Dropbox som täcks av typkontroller. Vi testade flera tillvägagångssätt för att lösa denna uppgift - från naturlig tillväxt av den typade kodbasen till att fokusera insatserna för mypy-teamet på statisk och dynamisk automatisk typutvinning. Slutligen skapades intrycket att det inte finns någon enkel vinnande strategi, men vi lyckades uppnå en snabb ökning av mängden annoterad kod genom att kombinera flera angreppssätt.

Som ett resultat hade vår största Python-repo (med backend-kod) nästan 4 miljoner rader annoterad kod. Arbetet med statisk typning av koden genomfördes under cirka tre år. Mypy stöder nu olika typer av rapporter om typnings täckning, som förenklar övervakningen av typningsprocessen. Specifikt kan vi generera rapporter för kod med typosäkerheter, som till exempel ersättande typer Any i annotationerna som inte kan verifieras, eller sådana som importerar externa bibliotek som saknar typanoteringar. Som en del av projektet för att förbättra noggrannheten i typkontrollen i Dropbox har vi bidragit till förbättringen av typdefinitionerna (de så kallade stub-filerna) för några populära open-source-bibliotek i det centraliserade Python-repoet typeshed.

Vi har implementerat (och standardiserat i efterföljande PEP) nya funktioner i typ systemet som möjliggör mer exakta typer för vissa specifika Python-mönster. Ett viktigt 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 att utöka typ systemet. Troligtvis blir vårt nästa steg att förbättra stödet för Python-funktioner som arbetar med siffror.

Antal rader av annoterad kod: server

Antal rader av annoterad kod: kund

Totalt antal rader av annoterad kod

Här är en översikt över de huvudsakliga funktionerna i de åtgärder vi har vidtagit för att öka mängden annoterad kod i Dropbox:

Strikthet i annoteringen. Vi har gradvis ökat kraven på strikthet för annotering av ny kod. Vi började med linternas rekommendationer, där vi föreslog att lägga till annotationer i filer som redan hade vissa annoteringar. Nu kräver vi att typannotationer finns i nya Python-filer och i de flesta befintliga filer.

Typningsrapporter. Vi skickar veckovisa rapporter till teamen om typningsgraden av deras kod och ger förslag på vad som bör annoteras först.

Främjande av mypy. Vi pratar om mypy på olika evenemang och kommunicerar med teamen för att hjälpa dem komma igång med typannotationer.

Undersökningar. Vi genomför periodiska användarundersökningar för att identifiera de största problemen. Vi är beredda att gå ganska långt för att lösa dessa problem (inklusive att skapa ett nytt språk för att påskynda mypy!).

Prestanda. Vi har avsevärt förbättrat prestandan av mypy genom att använda en daemon och mypyc. Detta gjordes för att jämna ut obehagligheter som uppstår vid annoteringen och för att kunna hantera stora kodmängder.

Integration med redaktörer. Vi har skapat verktyg för att stödja körning av mypy i de redaktörer som är populära i Dropbox. Detta inkluderar PyCharm, Vim och VS Code. Detta har gjort processen för att utföra arbetet med annotering av kod och verifiering av dess funktionalitet betydligt enklare. Liknande åtgärder är vanligt förekommande vid annotering av befintlig kod.

Statisk analys. Vi har skapat ett verktyg för att generera funktionssignaturer med hjälp av statiska analysverktyg. Detta verktyg kan endast fungera i jämförelsevis enkla situationer, men det har hjälpt oss att utan större ansträngning öka typbeteckningen av koden.

Stöd för externa bibliotek. Många av våra projekt använder verktyget SQLAlchemy. Det använder Python-dynamiska funktioner som typerna i PEP 484 inte kan modellera direkt. Enligt PEP 561 har vi skapat den nödvändiga stub-filen och skrivit ett plugin för mypy.öppen källkod), vilket förbättrar stöd för SQLAlchemy.

Svårigheter vi stötte på

Vägen till 4 miljoner rader typad kod har inte alltid varit lätt. På denna väg har vi stött på många hinder och gjort några misstag. Här är några av de problem vi stött på. Vi hoppas att vår berättelse kan hjälpa andra att undvika liknande problem.

Saknade filer. Vi började arbetet med att kontrollera enbart ett litet antal filer. Allt som inte ingick i dessa filer kontrollerades inte. Filer lades till i kontrollistan när de fick sina första annotationer. Om något importerades från en modul utanför kontrollområdet, handlade det om att arbeta med värden av typen Any, som överhuvudtaget inte kontrollerades. Detta ledde till en betydande förlust av typernas noggrannhet, särskilt i de tidiga migrationsstegen. Denna metod fungerade förvånansvärt bra, även om det ofta var så att tillägg av filer till kontrollområdet visade problem på andra delar av kodbasen. I det värsta fallet, när två isolerade kodområden förenades, där typerna oberoende var granskade, visade det sig att typerna i dessa områden var oförenliga med varandra. Detta ledde till att många ändringar behövde göras i annotationerna. Nu, när vi ser tillbaka, förstår vi att vi borde ha lagt till grundbiblioteksmodulerna i typerna för mypy så tidigt som möjligt. Det skulle ha gjort vårt arbete mycket mer förutsägbart.

Annotering av gammal kod. När vi började arbeta hade vi omkring 4 miljoner rader redan existerande Python-kod. Det stod klart att annotering av all denna kod var en tuff uppgift. Vi skapade ett verktyg kallat PyAnnotate som kan samla in typinformation under körning av tester och lägga till typannoteringar i koden baserat på den insamlade informationen. Men vi märkte ingen särskilt utbredd användning av detta verktyg. Insamlingen av typinformation var långsam, och automatiskt genererade annoteringar krävde ofta många manuella justeringar. Vi övervägde att automatiskt köra detta verktyg vid varje kodgranskning eller att samla in typinformation baserat på analys av ett litet antal verkliga nätverksförfrågningar, men beslutade att inte göra det, eftersom någon av dessa metoder skulle vara för riskabel.

I slutändan kan man konstatera att största delen av koden annoterades manuellt av dess ägare. Vi för att styra denna process i rätt riktning, förbereder rapporter om särskilt viktiga moduler och funktioner som behöver annoteras. Till exempel är det viktigt att förse biblioteksmodulen, som används på hundratals ställen, med typannoteringar. Men den gamla tjänsten som ersätts av den nya är inte lika viktig att annotera. Dessutom experimenterar vi med att använda statisk analys för att generera typannoteringar för den gamla koden.

Cykliska importer. Tidigare talade jag om cykliska importer (om "beroendetrassel"), vars existens har försvårat hastighetsoptimeringen av mypy. Vi har också fått arbeta hårt för att ge mypy stöd för alla typer av idiom som orsakas av dessa cykliska importer. Nyligen avslutade vi ett stort projekt för att redesigna systemet, vilket åtgärdade de flesta problem med mypy relaterade till cykliska importer. Dessa problem härstammade faktiskt från de mycket tidiga dagarna av projektet, ända från Alore, det undervisningsspråk som ursprungligen projektet mypy var inriktat på. Syntaxen i Alore gör det enkelt att hantera problem med cykliska importkommandon. Det moderna mypy har ärvt vissa begränsningar från sin tidiga, okomplicerade implementation (som passade bra för Alore). Python komplicerar arbetet med cykliska importer främst på grund av uttryckens tvetydighet. Till exempel kan en typalias faktiskt definieras under en assignmentsoperation. Mypy är inte alltid kapabel att upptäcka sådana saker förrän en stor del av importcykeln har behandlats. I Alore fanns det inga sådana tvetydigheter. Dåliga beslut som fattades i de tidiga utvecklingsstadierna av systemet kan överraska programmeraren flera år senare.

Sammanfattning: vägen till 5 miljoner rader kod och nya horisonter

Projektet mypy har kommit långt — från tidiga prototyper till ett system som kontrollerar typerna av produktionskod bestående av 4 miljoner rader. Under mypy:s utveckling har standardisering av typ-hints genomförts i Python. Idag har en stark ekosystem kring typning av Python-kod utvecklats. Det finns stöd för bibliotek, verktyg för IDE och redigerare, och flera typen kontrollerande system, var och en med sina egna fördelar och nackdelar.

Även om typkontroller redan uppfattas som en självklarhet på Dropbox, är jag övertygad om att vi fortfarande lever i gryningen av typning av Python-kod. Jag tror att teknologier för typkontroll kommer att fortsätta att utvecklas och förbättras.

Om du inte har använt typkontroller i ditt storskaliga Python-projekt, vet att det nu är en utmärkt tid att börja övergå till statisk typning. Jag har pratat med dem som gjort en sådan övergång. Ingen av dem har ångrat det. Typkontroll gör Python till ett språk som är betydligt mer lämpat för att utveckla stora projekt än "vanlig Python".

Kära läsare! Använder du typkontroller i dina Python-projekt?

Källa: habr.com