Vägen till att verifiera typer i 4 miljoner rader Python-kod. Del 1

Idag presenterar vi den första delen av översättningen av materialet om hur Dropbox arbetar med typkontroll av Python-kod.

På Dropbox skriver vi mycket i Python. Det är ett språk vi använder extremt mycket – både för backend-tjänster och för skrivbordsapplikationer. Vi använder också i stor utsträckning Go, TypeScript och Rust, men Python är vårt huvudspråk. Med tanke på vår storlek, som handlar om miljontals rader Python-kod, har den dynamiska typningen av sådan kod visat sig onödigt komplicera förståelsen och börjat påverka produktiviteten negativt. För att mildra detta problem började vi gradvis översätta vår kod till statisk typkontroll med hjälp av mypy. Detta är troligen det mest populära oberoende typkontrollsystemet för Python. Mypy är ett open source-projekt vars huvudutvecklare arbetar på Dropbox.

Dropbox var ett av de första företagen som implementerade statisk typkontroll i Python-kod i sådan skala. Numera används mypy i tusentals projekt. Det här verktyget har testats otaliga gånger, så att säga, 'i strid'. För att komma dit vi är idag har vi fått gå en lång väg. På den vägen har det funnits många misslyckade initiativ och misslyckade experiment. Detta material berättar historien om den statiska typkontrollen i Python – från dess krångliga början, som var en del av mitt vetenskapliga forskningsprojekt, till idag, då typkontroller och typförslag har blivit vanliga för otaliga utvecklare som skriver i Python. Dessa mekanismer stöds nu av många verktyg – som IDE:er och kodanalysatorer.

→ Läs del två

Varför behövs typkontroll?

Om du någonsin har använt det dynamiskt typade Python — kan du ha en viss förvirring över varför det har blivit så mycket uppståndelse kring statisk typning och mypy på sistone. Kanske gillar du Python just på grund av dess dynamiska typning, och det som händer gör dig helt enkelt irriterad. Nyckeln till värdet av statisk typning är skalet av lösningar: ju större ditt projekt är, desto mer lutar du mot statisk typning, och i slutändan, desto mer behöver du det verkligen.

Anta att ett visst projekt har nått storleken av tiotusentals rader, och det visar sig att flera programmerare arbetar på det. När vi betraktar ett sådant projekt kan vi, baserat på vår erfarenhet, säga att förståelsen av dess kod blir avgörande för att upprätthålla utvecklarnas produktivitet. Utan typannoteringar är det ofta svårt att ta reda på vilka argument som ska skickas till en funktion, eller vilka typer värden en viss funktion kan returnera. Här är typiska frågor som ofta är svåra att besvara utan typannoteringar:

• Kan denna funktion returnera None?
• Vad ska detta argument vara? items?
• Vad är typen av attributet? id: int är det, str, eller kanske någon anpassad typ?
• Ska detta argument vara en lista? Kan en tuple passeras till det?

Om du ser på följande kodsnutt, försåld med typannoteringar, och försöker besvara sådana frågor, visar det sig att det är en enkel uppgift:

class Resource:
    id: bytes
    ...
    def read_metadata(self, 
                      items: Sequence[str]) -> Dict[str, MetadataItem]:
        ...

• read_metadata returnerar inte None, eftersom returtypen inte är Optional[…].
• Argumentet items — det är en sekvens av strängar. Den kan inte itereras i godtycklig ordning.
• Attributet id är en byte-sträng.

I en perfekt värld skulle man kunna förvänta sig att alla sådana subtiliteter skulle beskrivas i den inbyggda dokumentationen (docstring). Men erfarenheten ger många exempel på att en sådan dokumentation ofta saknas i den kod man måste arbeta med. Även om sådan dokumentation finns i koden kan man inte räkna med att den är helt korrekt. Denna dokumentation kan vara otydlig, felaktig och lämna mycket utrymme för missförstånd. I stora team eller i stora projekt kan detta problem bli extremt påtagligt.

Även om Python fungerar utmärkt under de tidiga eller mellanstadierna av projekt, kan framgångsrika projekt och företag som använder Python i ett visst skede ställas inför en livsviktig fråga: "Måste vi skriva om allt i ett statiskt typat språk?".

Typkontrollsystem som mypy löser det ovan nämnda problemet genom att ge utvecklare ett formellt språk för att beskriva typer och genom att kontrollera att typbeskrivningarna stämmer överens med implementeringen av programmen (och, vilket inte är nödvändigt, kontrollerar deras existens). Generellt kan man säga att dessa system ger oss något liknande noggrant verifierad dokumentation.

Användningen av sådana system har även andra fördelar som redan är helt icke-triviala:

• Typkontrollsystemet kan upptäcka vissa småfel (och även större fel). Ett typiskt exempel är när man glömmer att hantera ett värde None eller något annat särskilt villkor.
• Refaktorering av koden blir betydligt enklare, eftersom typkontrollsystemet ofta ger mycket exakt information om vilken kod som behöver ändras. Vi behöver inte heller förlita oss på att ha 100% testtäckning av koden, vilket i alla fall vanligtvis är ogenomförbart. Vi behöver inte gräva ner oss i djupet av stacktrace-rapporter för att ta reda på vad som orsakar problemet.
• Även i stora projekt kan mypy ofta genomföra en fullständig typkontroll på bråkdelen av en sekund. Att köra tester tar vanligtvis tiotals sekunder eller till och med minuter. Typkontrollsystemet ger programmeraren omedelbar återkoppling och gör att denne kan arbeta snabbare. Det är inte längre nödvändigt att skriva ömtåliga och svåra att underhålla modulära tester som ersätter riktiga entiteter med mocks och patches bara för att snabbt få resultat av kodtester.

IDE:er och redaktörer som PyCharm eller Visual Studio Code använder möjligheterna med typannoteringar för att ge utvecklare funktioner som automatisk kodslutförning, felmarkering och stöd för ofta använda språkstrukturer. Det här är bara några av fördelarna med typning. För vissa programmerare är allt detta det främsta argumentet för typning. Det är något som ger fördelar så snart det implementeras i arbetet. Denna användning av typer kräver inte en separat typkontrollsystem som mypy, även om det bör nämnas att mypy hjälper till att säkerställa att typannoteringar och kod stämmer överens.

Bakgrunden till mypy

Historien om mypy började i Storbritannien, i Cambridge, flera år innan jag gick med i Dropbox. Jag arbetade, inom ramen för min doktorandstudie, med att enhetligt betrakta statiskt typade och dynamiska språk. Jag inspirerades av en artikel om gradvis typning av Jeremy Siek och Walid Taha, samt projektet Typed Racket. Jag försökte hitta sätt att använda samma programmeringsspråk för olika projekt – från små skript till kodbaser bestående av många miljoner rader. Samtidigt ville jag att något av projektets storlek skulle kunna genomföras utan alltför stora kompromisser. En viktig del av allt detta var idén om en gradvis övergång från en otypad prototyp till en grundligt testad statiskt typad färdig produkt. I dag tas dessa idéer till stor del för givna, men 2010 var det fortfarande ett problem som aktivt utforskades.

Mitt initiala arbete inom typkontroll var inte inriktat på Python. Istället använde jag ett litet "hemgjort" språk Alore. Här är ett exempel som hjälper dig att förstå vad som avses (typnoteringar är här valfria):

def Fib(n as Int) as Int
  if n <= 1
    return n
  else
    return Fib(n - 1) + Fib(n - 2)
  end
end

Att använda ett förenklat språk av egen utveckling är en vanlig metod inom vetenskaplig forskning. Detta beror i hög grad på att det möjliggör snabba experiment, och att det som inte är relevant för forskningen kan ignoreras utan problem. Faktiska programmeringsspråk är vanligtvis omfattande fenomen med komplexa implementationer, vilket saktar ner experimentprocessen. Men resultaten baserade på ett förenklat språk verkar lite misstänksamma, eftersom forskaren, i sitt arbete, kan ha offrat överväganden som är viktiga för praktisk användning av språken.

Mitt typkontrollverktyg för Alore verkade lovande, men jag ville testa det genom att utföra experiment med riktig kod, som det kan sägas inte fanns för Alore. Lyckligtvis var Alore språket i stor utsträckning baserat på samma idéer som Python. Det var ganska enkelt att omarbeta typkontrollverktyget så att det kunde fungera med Python-syntax och semantik. Detta gjorde det möjligt att försöka utföra typkontroll på öppen källkod Python-kod. Dessutom skrev jag en transpiler för att omvandla kod skriven i Alore till Python-kod och använde den för att översätta koden för mitt typkontrollverktyg. Nu hade jag ett typkontrollsystem skrivet i Python som stödde en delmängd av Python, en slags variant av detta språk! (Vissa arkitektoniska beslut som var rimliga för Alore passade dåligt för Python, vilket fortfarande märks i vissa delar av mypy-kodbasen.)

Faktum är att språket som stöddes av mitt typystem vid denna tidpunkt inte riktigt kunde kallas Python: det var en variant av Python på grund av vissa syntaxbegränsningar i typnoteringarna för Python 3.

Det såg ut som en blandning av Java och Python:

int fib(int n):
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

En av mina idéer då var att använda typannoteringar för att förbättra prestandan genom att kompilera denna variant av Python till C, eller kanske till JVM-bytekod. Jag kom så långt som till att skriva en prototyp av en kompilator, men övergav den idén eftersom typkontrollen visade sig vara tillräckligt användbar i sig själv.

Jag presenterade slutligen mitt projekt på PyCon 2013 i Santa Clara. Jag diskuterade också detta med Guido van Rossum, den generösa livstidens diktator i Python. Han övertygade mig att ge upp min egen syntax och hålla mig till standard Python 3-syntax. Python 3 stöder funktionsannoteringar, vilket gör att mitt exempel kunde skrivas om som visas nedan, vilket resulterade i ett normalt Python-program:

def fib(n: int) -> int:
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

Jag var tvungen att göra vissa kompromisser (jag vill särskilt påpeka att jag uppfann min egen syntax just därför). Specifikt stödde Python 3.3, den senaste versionen av språket vid den tiden, inte variabelannoteringar. Jag diskuterade med Guido via e-post olika möjligheter till syntax för sådana annoteringar. Vi beslöt oss för att använda kommentarer för variabler som angav typer. Detta uppnåddes målet, men såg ganska otympligt ut (Python 3.6 gav oss en mer trevlig syntax):

products = []  # type: List[str]  # Usch

Typkommentarer var dessutom användbara för att stödja Python 2, som inte har inbyggt stöd för typannoteringar:

f fib(n):
    # type: (int) -> int
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

Det visade sig att dessa (och andra) kompromisser egentligen inte hade någon större betydelse — fördelarna med statisk typkontroll ledde till att användarna snart glömde den inte helt perfekta syntaxen. Eftersom nu i Python-kod, där typer var kontrollerade, inte användes några speciella syntaxkonstruktioner, fortsatte existerande Python-verktyg och processer för kodhantering att fungera normalt, vilket betydligt underlättade för utvecklarna att lära sig det nya verktyget.

Guido övertygade dessutom mig att gå med i Dropbox efter att jag hade försvarat min examensarbete. Här börjar det mest intressanta i historien om mypy.

Fortsättning följer…

Kära läsare! Om du använder Python, ber vi dig berätta om vilka projekt du utvecklar på detta språk.

Källa: habr.com