Пътят към проверка на типове на 4 милиона реда Python код. Част 1

Днес ви представяме първата част от превода на материала за това как в Dropbox се занимават с контрол на типовете на Python кода.

В Dropbox пишем много на Python. Това е езикът, който използваме изключително широко - както за бекенд услуги, така и за настолни клиентски приложения. Също така, в значителна степен използваме Go, TypeScript и Rust, но Python е нашият основен език. Като се има предвид нашият мащаб, а става дума за милиони реда на Python код, стана ясно, че динамичната типизация на този код неоправдано усложни разбирането му и започна сериозно да влияе на производителността. За да смекчим този проблем, започнахме постепенно да прехвърляме нашия код към статична проверка на типовете с помощта на mypy. Това вероятно е най-популярната самостоятелна система за проверка на типове за Python. Mypy е проект с отворен код, а основните му разработчици работят в Dropbox.

Dropbox се оказа една от първите компании, които внедриха статична проверка на типовете в Python кода в подобен мащаб. В наши дни mypy се използва в хиляди проекти. Този инструмент е проверен безброй пъти, така да се каже, "в боя". За да стигнем дотам, където сме сега, ни беше нужно да извървим дълъг път. По време на този път имаше немалко неуспешни начинания и провалени експерименти. Този материал разказва историята на статичната проверка на типовете в Python - от самото й трудно начало, което беше част от моя научен изследователски проект, до днешния ден, когато проверките на типовете и подсказките за типове станаха рутинни за безброй разработчици, които пишат на Python. Тези механизми вече се поддържат от множество инструменти - като IDE и анализатори на код.

→ Прочетете втората част

Защо е необходима проверката на типовете?

Ако някога сте използвали динамично типизирания Python – може да имате известно недоразумение относно шума около статичната типизация и mypy напоследък. Или може би точно заради динамичната типизация Python харесвате езика, а случващото се просто ви разстройва. Ключът към стойността на статичната типизация е мащабът на решенията: колкото по-голям е вашият проект, толкова повече се накланяте към статичната типизация и в крайна сметка, толкова повече наистина ви е необходимо това.

Да предположим, че даден проект е достигнал размери от десетки хиляди редове и е установено, че по него работят няколко програмиста. Разглеждайки такъв проект, можем да кажем, базирайки се на нашия опит, че разбирането на неговия код ще бъде ключово за поддържането на продуктивността на разработчиците. Без анотации на типовете е трудно да се установи, например, какви аргументи трябва да се предадат на функцията или какви типове стойности може да върне функцията. Ето типични въпроси, на които често не е лесно да се отговори без използването на анотации на типовете:

• Може ли тази функция да върне None?
• Какъв трябва да бъде този аргумент елементи?
• Какъв е типът на атрибута id: int ли е това, str, или може би някакъв потребителски тип?
• Трябва ли този аргумент да бъде списък? Може ли да се предаде кортеж?

Ако погледнем следния фрагмент код, снабден с анотации на типовете, и опитаме да отговорим на подобни въпроси, ще се окаже, че това е най-простата задача:

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

• read_metadata не връща None, тъй като върнатият тип не е Optional[…].
• Аргумент елементи – това е последователност от низове. Не може да се итерара в произволен ред.
• Атрибут id – това е байтова низ.

В идеалния свят би било разумно да се очаква, че всички тези подробности ще бъдат описани в вградения документация (docstring). Но опитът предлага много примери за това, че подобна документация в кода, с който работим, често липсва. Дори ако такава документация присъства в кода, не бива да разчитаме на нейното абсолютно правилно съдържание. Тази документация може да бъде неясна, неточна и да оставя много възможности за неправилно разбиране. В големи екипи или при големи проекти, този проблем може да стане изключително остър.

Въпреки че Python показва отлични резултати на ранните или междинните етапи на проектите, в определен момент успешните проекти и компании, които използват Python, може да се сблъскат с жизненоважния въпрос: "Трябва ли да пренапишем всичко на статично типизиран език?".

Системите за проверка на типове, като mypy, решават споменатия проблем, като предоставят на разработчиците формален език за описание на типовете и проверяват, че описанията на типовете съответстват на реализацията на програмите (и, което не е задължително, проверяват тяхното съществуване). В общи линии, тези системи предлагат нещо като внимателно проверена документация.

Приложението на подобни системи има и други предимства, които вече съвсем не са тривиални:

• Системата за проверка на типове може да открие някои малки (а също така и не особено малки) грешки. Типичен пример е когато забравят да обработят стойност None или някакво друго специално условие.
• Рефactoring кодът става значително по-лесен, тъй като системата за проверка на типове често много точно указва кой код трябва да променим. При това не е необходимо да разчитаме на 100% покритие на кода с тестове, което, в крайна сметка, обикновено е неизпълнимо. Не е необходимо да проучваме дълбочините на отчетите за трасировка на стека, за да установим причината за проблема.
• Дори в големи проекти mypy често може да извърши пълна проверка на типовете за части от секундата. Изпълнението на тестовете обикновено отнема десетки секунди или дори минути. Системата за проверка на типовете предоставя на програмистите мигновена обратна връзка и им позволява да се справят по-бързо със задачите си. Не е нужно повече да пишат крехки и трудни за поддръжка модулни тестове, които заменят реалните обекти с фалшиви и патчове само за да получат по-бързи резултати от тестовете на кода.

IDE и редактори, като PyCharm или Visual Studio Code, използват възможностите на анотациите на типовете, за да предоставят на разработчиците функции за автоматично довършване на кода, подчертаване на грешките и поддръжка на често използвани езикови конструкции. И това е само част от предимствата, които предоставя типизацията. За някои програмисти всичко това е основният аргумент в полза на типизацията. Това е нещо, което носи полза веднага след внедряване в работата. Тази употреба на типовете не изисква прилагане на отделна система за проверка на типовете, като mypy, въпреки че е важно да се отбележи, че mypy помага да се поддържа съответствието между анотациите на типовете и кода.

Предистория на mypy

Историята на mypy започна във Великобритания, в Кеймбридж, няколко години преди да се присъединя към Dropbox. Работех, в рамките на докторската си дисертация, върху въпроса за унификацията на статично типизирани и динамични езици. Вдъхновен бях от статията за постепенна типизация на Джереми Сийк и Валид Тах, както и от проекта Typed Racket. Опитвах се да намеря начини за използване на един и същ програмен език за различни проекти — от малки скриптове до кодови бази, състоящи се от многомилионни редове. Същевременно исках проектите, независимо от мащаба, да не налагат твърде големи компромиси. Важна част от всичко това беше концепцията за постепенен преход от нетипизиран прототип на проекта към всестранно тестван статично типизиран готов продукт. В днешно време тези идеи в значителна степен се приемат за даденост, но през 2010 година това все още беше проблем, който активно се проучваше.

Първоначалната ми работа в областта на проверката на типовете не беше насочена към Python. Вместо него използвах малък „самоделен“ език AloreЕто пример, който ще ви помогне да разберете за какво става въпрос (анотациите на типовете тук не са задължителни):

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. Това ми позволи да изпробвам проверка на типовете в отворен 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. Той ме убеди да се откажа от собствения синтаксис и да следвам стандартния синтаксис на 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]  # Ужасно

Коментарите с типове също бяха полезни за поддръжка на 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, моля, споделете информация за проектите с какъв мащаб разработвате на този език.

Източник: habr.com