Пътят към проверка на типовете 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 именно заради динамичната му типизация, а всичко това ви разстройва. Ключът към стойността на статичната типизация е мащаба на решенията: колкото по-голям е проектът ви, толкова по-силно се насочвате към статичната типизация, и в крайна сметка, толкова повече ви е наистина необходимо.

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

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

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

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

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

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

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

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

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

• Системата за проверка на типове може да открие някои малки (и също така не особено малки) грешки. Типичен пример е, когато забравим да обработим стойност Няма или някакво друго специално условие.
• Рефакторингът на кода значително се опростява, тъй като системата за проверка на типове често много точно указва какъв код трябва да бъде променен. В допълнение, не е необходимо да разчитаме на 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, в който няма вградена поддръжка на анотации на типовете:

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

Оказа се, че тези (и други) компромиси всъщност нямат особено значение — предимствата на статичната типизация доведоха до това, че потребителите бързо забравиха за не съвсем идеалния синтаксис. Тъй като сега в Python код, в който се контролираха типовете, не се използваха специални синтактични конструкции, съществуващите инструменти и процеси за обработка на кода продължиха да работят нормално, което значително улесни усвояването на новия инструмент от разработчиците.

Гвидо, освен това, ме убеди да се присъединя към Dropbox след като защитих дипломната си работа. Тук започва най-интересното в историята на mypy.

Продължението следва…

Уважаеми читатели! Ако използвате Python, моля, споделете какъв мащаб на проекти разработвате на този език.

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