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

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

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

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

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

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

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