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

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

→ Предишни части: първата и втора

Постигане на 4 милиона реда типизирания код

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

В резултат в нашето най-голямо Python хранилище (с бекенд код) броят на редовете на анотиран код достигна почти 4 милиона. Работата по статичната типизация на кода беше извършена за около три години. Mypy сега поддържа различни видове отчети за покритие на кода с типове, които улесняват наблюдението на напредъка в типизацията. В частност, можем да генерираме отчети по код с неопределености в типове, като например явното използване на тип Any в анотациите, които не могат да бъдат проверени, или като импорт на външни библиотеки, в които няма анотации на типове. В рамките на проекта за подобряване точността на проверката на типове в Dropbox, направихме принос за подобряване на определенията на типове (т.нар. stub файлове) за някои популярни опенсорс библиотеки в централизиран Python хранилище typeshed.

Реализирахме (и стандартизирахме в последващите PEP) нови възможности на системата за типове, които позволяват използването на по-точни типове за някои специфични Python модели. Забележителен пример за това е TypeDict, който предоставя типове за JSON-подобни речници с фиксиран набор от стрингови ключове, всеки от които има стойност от собствен тип. Ще продължим да разширяваме системата за типове. Вероятно следващата ни стъпка ще бъде подобряването на поддръжката на възможностите на Python за работа с числа.

Брой редове на анотирания код: сървър

Брой редове на анотиран код: клиент

Общо брой редове на анотиран код

Ето преглед на основните функции на действията, които предприехме, за да увеличим обема на анотиран код в Dropbox:

Строгост на анотиране. Постепенно увеличавахме изискванията за строгост на анотирането на новия код. Започнахме с предложения от линтера, които препоръчваха добавяне на анотации в файлове, в които вече има някои анотации. Сега изискваме наличието на анотации на типове в новите Python файлове и в повечето съществуващи файлове.

Доклади за типизиране. Изпращаме на екипите седмични доклади за нивото на типизиране на техния код и даваме съвети относно това, какво точно трябва да се анотира на първо място.

Популяризиране на mypy. Говорим за mypy на различни събития и комуникираме с екипите, помагайки им да започнат да използват анотации на типове.

Анкети. Провеждаме периодични анкети сред потребителите, за да идентифицираме основните проблеми. Готови сме да направим достатъчно, за да решим тези проблеми (включително създаването на нов език, за да ускорим mypy!).

Производителност. Значително подобрихме производителността на mypy, благодарение на използването на демон и mypyc. Направено е, за да се изгладят неудобствата, които възникват по време на анотиране, и за да можем да работим с големи обеми код.

Интеграция с редактори. Създадохме инструменти за поддръжка на изпълнението на mypy в редактори, популярни в Dropbox. Включени са PyCharm, Vim и VS Code. Това значително опрости процеса на анотиране на код и проверка на неговата работоспособност. Подобни действия обикновено са характерни за анотиране на съществуващ код.

Статичен анализ. Създадохме инструмент за извеждане на сигнатури на функции, използвайки средства за статичен анализ. Този инструмент може да работи само в сравнително прости ситуации, но ни помогна без усилия да увеличим покритието на кода с типове.

Поддръжка на външни библиотеки. В много от нашите проекти се използва набор от инструменти SQLAlchemy. В него се прилагат динамичните възможности на Python, които типовете PEP 484 не могат да моделират директно. Съгласно PEP 561, създадохме съответния stub файл и написахме плъгин за mypy (отворен код), подобряваща поддръжката на SQLAlchemy.

Трудностите, пред които се изправихме

Пътят към 4 милиона реда типизиран код не винаги беше лесен за нас. По този път срещнахме много трудности и допуснахме няколко грешки. Ето някои от проблемите, с които се сблъскахме. Надяваме се, че разказът за тях ще помогне на други да избегнат подобни трудности.

Пропуснати файлове. Започнахме работа с проверка само на малък обем файлове. Всичко, което не попадаше в броя на тези файлове, не се проверяваше. Файловете в списъка за проверка се добавяха, когато в тях се появяваха първите анотации. Ако нещо се внасяше от модул, разположен извън обхвата на проверката, се касаеше за работа с типове Any, които изобщо не се проверяваха. Това доведе до значителна загуба на точност на типизацията, особено на ранните етапи на миграцията. Този подход работеше изненадващо добре, макар че типичното беше, че добавянето на файлове в обхвата на проверката разкриваше проблеми в други части на кодовата база. В най-лошия случай, когато се събираха две изолирани области на кода, в които типове бяха проверени независимо взаимно, се оказваше, че типове на тези области не са съвместими помежду си. Това водеше до нужда от внасяне на множество изменения в анотациите. Сега, оглеждайки се назад, разбираме, че трябваше да добавим основни библиотечни модули в обхвата на проверката на типовете mypy възможно най-рано. Това би направило работата ни много по-предсказуема.

Анотиране на стар код. Когато започвахме работа, имахме около 4 милиона реда съществуващ Python код. Беше ясно, че анотирането на целия този код е задача, която не е лесна. Създадохме инструмент, наречен PyAnnotate, който може да събира информация за типове по време на изпълнението на тестове и уме да добавя в кода анотации на типове, базирани на събраната информация. Въпреки това, не забелязахме особено широко внедряване на този инструмент. Събирането на информация за типове беше бавно, а автоматично генерираните анотации често изискваха много ръчни корекции. Размисляхме за автоматично стартиране на това средство при всяка проверка на кода, или за събиране на информация за типове, базирана на анализа на определено малко количество реални мрежови заявки, но решихме да не го правим, тъй като всеки от тези подходи беше твърде рисков.

В крайна сметка можем да отбележим, че голяма част от кода беше ръчно анотирана от неговите собственици. Ние, за да насочим този процес в правилната посока, подготвяме отчети за особено важни модули и функции, които трябва да бъдат анотирани. Например, важно е да снабдим с анотации тип библиотечния модул, използван в стотици места. Но старият сервиз, който се заменя с нов, вече не е толкова важен за анотиране. Освен това, експериментираме с използването на статичен анализ за генериране на анотации на типове за стария код.

Циклични импорти. По-горе говорих за цикличните импорти (или "клубки зависимости"), чието съществуване усложняваше ускорението на mypy. Освен това, трябваше сериозно да работим, за да предоставим на mypy поддръжка за всички видове идиоми, причиняващи възникването на тези циклични импорти. Наскоро проведохме голям проект за redesign на системата, който поправи повечето проблеми на mypy, свързани с цикличните импорти. Тези проблеми всъщност произлизат от доста ранни дни на проекта, още от Alore, учебния език, на който първоначално беше насочен проектът mypy. Синтаксисът на Alore позволява лесно да се решават проблемите с цикличните команди за импортиране. Съвременният mypy наследи някои ограничения от своята ранна проста реализация (която пасваше отлично на Alore). Python затруднява работата с циклични импорти основно поради многозначността на изразите. Например, по време на операцията за присвояване стойността може всъщност да се определи от псевдоним на типа. Mypy не винаги е в състояние да разпознае такива неща, докато голяма част от цикъла на импорта не бъде обработена. В Alore нямаше такива многозначности. Неуспешните решения, взети в ранните етапи на разработка на системата, могат да донесат неприятна изненада на програмиста след много години.

Резюме: пътят към 5 милиона реда код и нови хоризонти

Проектът mypy премина дълъг път - от ранни прототипи до система, с помощта на която се контролират типовете на продукционния код с обем от 4 милиона реда. По време на развитието mypy беше извършена стандартизация на подсказките за типове в Python. Днес около типизацията на Python-код се е развила мощна екосистема. В нея има место за поддръжка на библиотеки, за помощни средства за IDE и редактори, а също така има няколко системи за контрол на типовете, всяка от които притежава свои плюсове и минуси.

Въпреки че проверката на типовете вече се възприема в Dropbox като нещо съвсем нормално, съм сигурен, че все още живеем в зората на типизацията на Python-код. Мисля, че технологиите за проверка на типовете ще продължат да се развиват и усъвършенстват.

Ако все още не сте използвали проверки на типове в голям проект на Python, знайте, че сега е много подходящо време да започнете прехода към статична типизация. Разговарях с хора, които направиха подобен преход. Никой от тях не съжалява за това. Контролът на типовете прави Python език, който е значително по-подходящ за разработка на големи проекти в сравнение с "обикновения Python".

Уважаеми читатели! Използвате ли контрол на типовете в своите Python проекти?

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