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

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

Dropbox пише много на Python. Това е език, който използваме изключително широко, както за back-end услуги, така и за настолни клиентски приложения. Ние също използваме много Go, TypeScript и Rust, но Python е основният ни език. Имайки предвид нашия мащаб, а говорим за милиони редове код на 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. Участвал съм, като част от моите докторски изследвания, в обединяването на статично типизирани и динамични езици. Бях вдъхновен от статия за инкременталното въвеждане на текст от Jeremy Siek и Walid Taha и от проекта Typed Racket. Опитах се да намеря начини да използвам един и същ език за програмиране за различни проекти - от малки скриптове до кодови бази, състоящи се от много милиони редове. В същото време исках да гарантирам, че в проект от всякакъв мащаб няма да се налага да се правят твърде големи компромиси. Важна част от всичко това беше идеята за постепенно преминаване от нетипизиран прототипен проект към цялостно тестван статично типизиран завършен продукт. В наши дни тези идеи до голяма степен се приемат за даденост, но през 2010 г. това беше проблем, който все още се проучваше активно.

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

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, най-новата версия на езика по това време, не поддържа анотации на променливи. Обсъдих с Guido по имейл различни възможности за синтактичен дизайн на такива анотации. Решихме да използваме типови коментари за променливи. Това изпълни предвидената цел, но беше донякъде тромаво (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