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

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

→ Прочетете първа част

Официален тип поддръжка (PEP 484)

Проведохме първите си сериозни експерименти с mypy в Dropbox по време на Hack Week 2014. Hack Week е едноседмично събитие, организирано от Dropbox. През това време служителите могат да работят каквото си поискат! Някои от най-известните технологични проекти на Dropbox започнаха на събития като тези. В резултат на този експеримент заключихме, че mypy изглежда обещаващо, въпреки че проектът все още не е готов за широко използване.

По това време идеята за стандартизиране на системите за подсказване от тип Python витаеше във въздуха. Както казах, от Python 3.0 беше възможно да се използват анотации на типове за функции, но това бяха само произволни изрази, без дефиниран синтаксис и семантика. По време на изпълнение на програмата тези анотации в по-голямата си част просто бяха игнорирани. След Hack Week започнахме да работим по стандартизиране на семантиката. Тази работа доведе до появата PEP 484 (Guido van Rossum, Łukasz Langa и аз си сътрудничихме по този документ).

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

Синтаксисът на намек за тип, който в крайна сметка беше приет, беше много подобен на това, което mypy поддържаше по това време. PEP 484 беше пуснат с Python 3.5 през 2015 г. Python вече не беше динамично въведен език. Обичам да мисля за това събитие като за важен крайъгълен камък в историята на Python.

Начало на миграцията

В края на 2015 г. Dropbox създаде екип от трима души, които да работят върху mypy. Те включват Гуидо ван Росъм, Грег Прайс и Дейвид Фишър. От този момент нататък ситуацията започва да се развива изключително бързо. Първата пречка пред растежа на mypy беше производителността. Както намекнах по-горе, в ранните дни на проекта мислех да преведа имплементацията на mypy в C, но тази идея засега беше зачеркната от списъка. Останахме да работим със системата с помощта на интерпретатора CPython, който не е достатъчно бърз за инструменти като mypy. (Проектът PyPy, алтернативна реализация на Python с JIT компилатор, също не ни помогна.)

За щастие тук на помощ ни дойдоха някои подобрения в алгоритмите. Първият мощен „ускорител“ беше прилагането на инкрементална проверка. Идеята зад това подобрение беше проста: ако всички зависимости на модула не са се променили от предишното изпълнение на mypy, тогава можем да използваме данните, кеширани по време на предишното изпълнение, докато работим със зависимости. Трябваше само да извършим проверка на типа на модифицираните файлове и на файловете, които зависят от тях. Mypy дори отиде малко по-далеч: ако външният интерфейс на даден модул не се промени, mypy предположи, че други модули, които импортират този модул, не трябва да бъдат проверявани отново.

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

Това беше период на бързо и естествено приемане на проверката на типа в Dropbox. До края на 2016 г. вече имахме приблизително 420000 XNUMX реда код на Python с анотации за типове. Много потребители бяха ентусиазирани относно проверката на типа. Все повече екипи за разработка използваха Dropbox mypy.

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

Повече производителност!

Постепенните проверки направиха mypy по-бърз, но инструментът все още не беше достатъчно бърз. Много постепенни проверки продължиха около минута. Причината за това е цикличният внос. Това вероятно няма да изненада никой, който е работил с големи кодови бази, написани на Python. Имахме комплекти от стотици модули, всеки от които индиректно импортира всички останали. Ако някой файл в цикъл за импортиране беше променен, mypy трябваше да обработи всички файлове в този цикъл и често всички модули, които импортират модули от този цикъл. Един такъв цикъл беше прословутата „заплетена зависимост“, която причини много проблеми в Dropbox. След като тази структура съдържаше няколкостотин модула, докато беше импортирана, пряко или косвено, много тестове, тя също беше използвана в производствен код.

Обмисляхме възможността за „разплитане“ на кръгови зависимости, но нямахме ресурсите да го направим. Имаше твърде много код, с който не бяхме запознати. В резултат на това стигнахме до алтернативен подход. Решихме да накараме mypy да работи бързо дори при наличието на „заплетени зависимости“. Постигнахме тази цел с помощта на демона mypy. Демонът е сървърен процес, който реализира две интересни възможности. Първо, той съхранява информация за цялата кодова база в паметта. Това означава, че всеки път, когато стартирате mypy, не е нужно да зареждате кеширани данни, свързани с хиляди импортирани зависимости. На второ място, той внимателно, на ниво малки структурни единици, анализира зависимостите между функциите и други единици. Например, ако функцията foo извиква функция bar, тогава има зависимост foo от bar. Когато даден файл се промени, демонът първо, изолирано, обработва само променения файл. След това разглежда видими отвън промени в този файл, като например променени функционални сигнатури. Демонът използва подробна информация за импортирането само за двойна проверка на онези функции, които действително използват модифицираната функция. Обикновено при този подход трябва да проверите много малко функции.

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

Още повече производителност!

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

Решихме да се върнем към една от по-ранните идеи относно mypy. А именно, да конвертирате Python код в C код. Експериментирането с Cython (система, която ви позволява да превеждате код, написан на Python, в C код) не ни даде никакво видимо ускоряване, така че решихме да съживим идеята да напишем наш собствен компилатор. Тъй като кодовата база на mypy (написана на Python) вече съдържа всички необходими анотации за типове, решихме, че ще си струва да опитаме да използваме тези анотации, за да ускорим системата. Бързо създадох прототип, за да тествам тази идея. Той показа повече от 10-кратно увеличение на производителността при различни микро-бенчмаркове. Нашата идея беше да компилираме Python модули в C модули с помощта на Cython и да превърнем анотациите на типа в проверки на типа по време на изпълнение (обикновено анотациите на типа се игнорират по време на изпълнение и се използват само от системи за проверка на типа). Всъщност планирахме да преведем имплементацията mypy от Python на език, който е проектиран да бъде статично въведен, който ще изглежда (и в по-голямата си част ще работи) точно като Python. (Този вид междуезична миграция се е превърнала в нещо като традиция на проекта mypy. Оригиналната реализация на mypy е написана на Alore, след това имаше синтактичен хибрид на Java и Python).

Фокусирането върху API за разширение CPython беше от ключово значение, за да не се загубят способностите за управление на проекти. Не беше необходимо да внедряваме виртуална машина или библиотеки, от които mypy се нуждаеше. Освен това пак ще имаме достъп до цялата екосистема на Python и всички инструменти (като pytest). Това означаваше, че можем да продължим да използваме интерпретиран код на Python по време на разработката, което ни позволява да продължим да работим с много бърз модел на извършване на промени в кода и тестването му, вместо да чакаме кодът да се компилира. Изглеждаше, че се справяме страхотно със седянето на два стола, така да се каже, и ни хареса.

Компилаторът, който нарекохме mypyc (тъй като използва mypy като преден край за анализ на типове), се оказа много успешен проект. Като цяло постигнахме приблизително 4 пъти ускорение за чести изпълнения на mypy без кеширане. Разработването на ядрото на проекта mypyc отне на малък екип от Майкъл Съливан, Иван Левкивски, Хю Хан и мен около 4 календарни месеца. Това количество работа беше много по-малко от това, което би било необходимо за пренаписване на mypy, например, в C++ или Go. И трябваше да направим много по-малко промени в проекта, отколкото би трябвало да направим, когато го пренаписваме на друг език. Освен това се надявахме, че можем да доведем mypyc до такова ниво, че други програмисти на Dropbox да могат да го използват, за да компилират и ускорят своя код.

За да постигнем това ниво на производителност, трябваше да приложим някои интересни инженерни решения. По този начин компилаторът може да ускори много операции, като използва бързи конструкции на ниско ниво на C. Например, компилирано извикване на функция се превежда в извикване на C функция. И такова извикване е много по-бързо от извикването на интерпретирана функция. Някои операции, като търсене в речник, все още включват използване на редовни C-API извиквания от CPython, които са само незначително по-бързи, когато са компилирани. Успяхме да елиминираме допълнителното натоварване на системата, създадено от интерпретацията, но това в този случай даде само малка печалба по отношение на производителността.

За да идентифицираме най-често срещаните „бавни“ операции, извършихме профилиране на код. Въоръжени с тези данни, ние се опитахме или да настроим mypyc, така че да генерира по-бърз C код за такива операции, или да пренапишем съответния код на Python, използвайки по-бързи операции (и понякога просто нямахме достатъчно просто решение за този или друг проблем) . Пренаписването на кода на Python често беше по-лесно решение на проблема, отколкото компилаторът автоматично да извърши същата трансформация. В дългосрочен план искахме да автоматизираме много от тези трансформации, но по това време бяхме фокусирани върху ускоряването на mypy с минимални усилия. И придвижвайки се към тази цел, ние отрязахме няколко ъгъла.

За да се продължи ...

Уважаеми читатели! Какви бяха впечатленията ви от проекта mypy, когато научихте за съществуването му?

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