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

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

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

Достигане на 4 милиона реда въведен код

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

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

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

Брой редове с пояснен код: сървър

Брой редове с пояснен код: клиент

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

Ето преглед на основните характеристики на нещата, които направихме, за да увеличим количеството анотиран код в Dropbox:

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

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

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

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

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

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

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

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

Трудности, които срещнахме

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

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

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

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

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

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

Проектът mypy извървя дълъг път - от ранни прототипи до система, която контролира 4 милиона реда производствени кодови типове. С развитието на mypy типовите съвети на Python бяха стандартизирани. Тези дни се е развила мощна екосистема около въвеждането на код на Python. Има място за поддръжка на библиотека, съдържа помощни инструменти за IDE и редактори, има няколко системи за контрол на типа, всяка от които има своите плюсове и минуси.

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

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

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

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