Патот до проверка на типот на 4 милиони линии од Python код. Дел 1

Денеска ви го пренесуваме првиот дел од преводот на материјалот за тоа како Dropbox се справува со контролата на типот на кодот на Python.

Dropbox пишува многу во Python. Тоа е јазик што го користиме исклучително широко, како за back-end услуги, така и за десктоп-клиент апликации. Исто така, многу користиме Go, TypeScript и Rust, но Python е нашиот главен јазик. Со оглед на нашата скала, а ние зборуваме за милиони линии од кодот на Пајтон, се покажа дека динамичкото пишување на таков код непотребно го комплицираше неговото разбирање и почна сериозно да влијае на продуктивноста на трудот. За да го ублажиме овој проблем, почнавме постепено да го префрламе нашиот код кон проверка на статички тип користејќи mypy. Ова е веројатно најпопуларниот самостоен систем за проверка на типот за Python. Mypy е проект со отворен код, неговите главни развивачи работат во Dropbox.

Dropbox беше една од првите компании што имплементираше проверка на статички тип во кодот на Python во оваа скала. Mypy се користи во илјадници проекти овие денови. Оваа алатка безброј пати, како што велат, „тестиран во битка“. Поминавме долг пат за да стигнеме до каде што сме сега. На патот, имаше многу неуспешни зафати и неуспешни експерименти. Овој пост ја опфаќа историјата на проверка на статички тип во Python, од неговите карпести почетоци како дел од мојот истражувачки проект, до денес, кога проверката на типот и навестувањето на типот станаа вообичаени за безброј програмери кои пишуваат во Python. Овие механизми сега се поддржани од многу алатки како што се IDE и анализатори на кодови.

→ Прочитајте го вториот дел

Зошто е неопходна проверка на типот?

Ако некогаш сте користеле динамички пишуван Python, можеби ќе имате одредена конфузија зошто во последно време се крена толкава врева околу статичкото пишување и mypy. Или можеби ви се допаѓа Python токму поради неговото динамично пишување, а она што се случува едноставно ве вознемирува. Клучот за вредноста на статичкото пишување е размерот на решенијата: колку е поголем вашиот проект, толку повеќе се приклонувате кон статично пишување, и на крајот, толку повеќе ви треба.

Да претпоставиме дека одреден проект достигнал големина од десетици илјади линии и се покажа дека неколку програмери работат на него. Гледајќи сличен проект, врз основа на нашето искуство, можеме да кажеме дека разбирањето на неговиот код ќе биде клучот за одржување на продуктивни програмери. Без прибелешки за типови, може да биде тешко да се открие, на пример, кои аргументи да се пренесат на функцијата или какви типови може да се вратат. Еве типични прашања на кои често е тешко да се одговори без користење на прибелешки за типови:

• Дали оваа функција може да се врати None?
• Каков треба да биде овој аргумент? items?
• Кој е типот на атрибутот id: int дали е, str, или можеби некој прилагоден тип?
• Дали овој аргумент треба да биде список? Дали е можно да му се предаде торка?

Ако го погледнете следниов фрагмент од код со прибелешки и се обидете да одговорите на слични прашања, ќе излезе дека ова е наједноставната задача:

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

• read_metadata не се враќа None, бидејќи типот на враќање не е Optional[…].
• Аргумент items е низа од линии. Не може да се повторува случајно.
• Атрибут id е низа од бајти.

Во идеален свет, би се очекувало дека сите такви суптилности ќе бидат опишани во вградената документација (docstring). Но, искуството дава многу примери за фактот дека таквата документација често не е забележана во кодот со кој треба да работите. Дури и ако таквата документација е присутна во кодот, не може да се смета на нејзината апсолутна исправност. Оваа документација може да биде нејасна, неточна и отворена за недоразбирања. Во големи тимови или големи проекти, овој проблем може да стане исклучително акутен.

Додека Python се истакнува во раните или средните фази на проектите, во одреден момент успешните проекти и компаниите кои користат Python може да се соочат со виталното прашање: „Дали треба да препишуваме сè на статички отчукуван јазик?“.

Системите за проверка на типови како mypy го решаваат горенаведениот проблем со тоа што му обезбедуваат на развивачот формален јазик за опишување типови и со проверка дали декларациите за тип се совпаѓаат со имплементацијата на програмата (и, по избор, проверувајќи го нивното постоење). Генерално, можеме да кажеме дека овие системи ни ставаат на располагање нешто како внимателно проверена документација.

Употребата на такви системи има и други предности, и тие се веќе целосно нетривијални:

• Системот за проверка на тип може да открие некои мали (и не толку мали) грешки. Типичен пример е кога забораваат да обработат вредност None или некоја друга посебна состојба.
• Рефакторирањето на кодот е значително поедноставено бидејќи системот за проверка на типот честопати е многу точен за тоа кој код треба да се смени. Во исто време, не треба да се надеваме на 100% покриеност на кодот со тестови, што, во секој случај, обично не е изводливо. Не треба да истражуваме во длабочините на трагата на оџакот за да ја откриеме причината за проблемот.
• Дури и на големи проекти, mypy често може да направи целосна проверка на типот во дел од секундата. И извршувањето на тестовите обично трае десетици секунди или дури минути. Системот за проверка на типот му дава инстант повратни информации на програмерот и му овозможува побрзо да ја врши својата работа. Тој повеќе не треба да пишува кревки и тешки за одржување единечни тестови кои ги заменуваат вистинските ентитети со потсмевки и закрпи само за побрзо да ги добие резултатите од тестот на кодот.

IDE-ите и уредниците како PyCharm или Visual Studio Code ја користат моќта на прибелешките за типови за да им обезбедат на програмерите комплетирање на кодот, истакнување на грешки и поддршка за најчесто користените јазични конструкции. А ова се само дел од придобивките од пишувањето. За некои програмери, сето ова е главниот аргумент во корист на пишувањето. Ова е нешто што има корист веднаш по имплементацијата. Овој случај на употреба за типови не бара посебен систем за проверка на типот, како што е mypy, иако треба да се забележи дека mypy помага прибелешките за типови да бидат конзистентни со кодот.

Позадина на mypy

Историјата на mypy започна во ОК, во Кембриџ, неколку години пред да се приклучам на Dropbox. Вклучен сум, како дел од моето докторско истражување, во обединување на статички типизирани и динамички јазици. Бев инспириран од една статија за постепено пишување од Џереми Сиек и Валид Таха, и од проектот „Тишан рекет“. Се обидов да најдам начини да го користам истиот програмски јазик за различни проекти - од мали скрипти до бази на кодови што се состојат од многу милиони линии. Во исто време, сакав да се осигурам дека во проект од кој било обем, човек нема да мора да прави преголеми компромиси. Важен дел од сето ова беше идејата за постепено преминување од невтипизиран прототип на проект кон сеопфатно тестиран статички типизиран готов производ. Деновиве овие идеи во голема мера се земаат здраво за готово, но во 2010 година тоа беше проблем кој сè уште активно се истражуваше.

Мојата оригинална работа во проверка на типот не беше насочена кон Пајтон. Наместо тоа, користев мал „домашен“ јазик Алоре. Еве еден пример што ќе ви овозможи да разберете за што зборуваме (прибелешките за типот се опционални овде):

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

Користењето на поедноставен мајчин јазик е вообичаен пристап што се користи во научното истражување. Ова е така, не само затоа што ви овозможува брзо да спроведете експерименти, а исто така и поради фактот што она што нема никаква врска со студијата може лесно да се игнорира. Програмските јазици во реалниот свет имаат тенденција да бидат феномени од големи размери со сложени имплементации, а тоа го забавува експериментирањето. Сепак, сите резултати засновани на поедноставен јазик изгледаат малку сомнителни, бидејќи при добивањето на овие резултати истражувачот можеби жртвувал размислувања важни за практичната употреба на јазиците.

Мојата проверка на типови за Alore изгледаше многу ветувачка, но сакав да ја тестирам со експериментирање со вистински код, кој, може да се каже, не беше напишан во Alore. За моја среќа, јазикот Alore во голема мера се засноваше на истите идеи како и Python. Беше доволно лесно да се преработи машината за да може да работи со синтаксата и семантиката на Пајтон. Ова ни овозможи да пробаме проверка на типот во кодот на Python со отворен код. Дополнително, напишав транспајлер за конвертирање на кодот напишан во Alore во код на Python и го користев за да го преведам мојот код за проверка на типот. Сега имав систем за проверка на типот напишан во Python кој поддржуваше подмножество на Python, некој вид на тој јазик! (Одредени архитектонски одлуки кои имаа смисла за Alore беа слабо прилагодени за Python, и тоа сè уште е забележливо во делови од базата на кодови mypy.)

Всушност, јазикот поддржан од мојот типски систем во овој момент не можеше сосема да се нарече Python: тој беше варијанта на Python поради некои ограничувања на синтаксата за прибелешки од типот Python 3.

Изгледаше како мешавина од Java и Python:

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

Една од моите идеи во тоа време беше да користам прибелешки за да ги подобрам перформансите со компајлирање на овој вид Python во C, или можеби JVM бајтекод. Стигнав до фаза на пишување прототип на компајлерот, но ја напуштив оваа идеја, бидејќи самото проверка на типот изгледаше доста корисно.

На крајот го презентирав мојот проект на PyCon 2013 во Санта Клара. Зборував за ова и со Гвидо ван Росум, добронамерниот диктатор на Пајтон доживотно. Тој ме убеди да ја отфрлам сопствената синтакса и да се придржувам до стандардната синтакса на Python 3. Python 3 поддржува прибелешки за функции, така што мојот пример може да се преработи како што е прикажано подолу, што резултира со нормална Python програма:

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

Морав да направам некои компромиси (најпрво, сакам да забележам дека измислив сопствена синтакса токму поради оваа причина). Особено, Python 3.3, најновата верзија на јазикот во тоа време, не поддржуваше променливи прибелешки. Разговарав со Гвидо преку е-пошта за различни можности за синтаксичко дизајнирање на такви прибелешки. Решивме да користиме коментари за типови за променливи. Ова ја послужи намената, но беше донекаде незгодно (Python 3.6 ни даде поубава синтакса):

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

Коментарите за пишување исто така беа корисни за поддршка на Python 2, кој нема вградена поддршка за прибелешки за типови:

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

Се покажа дека овие (и други) компромиси не се навистина важни - придобивките од статичкото пишување значеа дека корисниците наскоро заборавија на помалку од идеалната синтакса. Бидејќи не беа користени посебни синтаксички конструкции во проверениот код на Python, постоечките Python алатки и процесите за обработка на кодот продолжија да работат нормално, што им олеснува на програмерите да ја научат новата алатка.

Гвидо, исто така, ме убеди да се приклучам на Dropbox откако го завршив мојот дипломски труд. Тука започнува најинтересниот дел од приказната за mypy.

Да се ​​продолжи ...

Почитувани читатели! Ако користите Python, кажете ни за обемот на проекти што ги развивате на овој јазик.

Извор: www.habr.com