Патот до проверка на типот на 4 милиони линии од Python код. Дел 3

Ви го претставуваме третиот дел од преводот на материјалот за патеката што ја помина Dropbox при имплементирање на систем за проверка на типот за кодот на Python.

→ Претходни делови: прво и Вториот

Достигнувајќи 4 милиони линии внесен код

Друг голем предизвик (и втор најчест проблем меѓу испитаните внатрешно) беше зголемувањето на количината на код покриен со проверки на типови во Dropbox. Пробавме неколку пристапи за да го решиме овој проблем, од природно зголемување на големината на впишаната база на кодови до фокусирање на напорите на тимот mypy на статичко и динамично автоматско заклучување на типот. На крајот, се чинеше дека нема едноставна стратегија за победа, но успеавме да постигнеме брз раст на обемот на означениот код со комбинирање на многу пристапи.

Како резултат на тоа, нашето најголемо складиште на Python (со код за заднина) има скоро 4 милиони линии на означен код. Работата на статичко пишување код беше завршена за приближно три години. Mypy сега поддржува различни видови извештаи за покривање кодови што го олеснуваат следењето на напредокот на пишувањето. Конкретно, можеме да генерираме извештаи за код со нејаснотии во типовите, како што е, на пример, експлицитна употреба на тип Any во прибелешки што не можат да се потврдат или со работи како увоз на библиотеки од трети страни кои немаат прибелешки за типови. Како дел од проектот за подобрување на точноста на проверката на типот во Dropbox, придонесовме за подобрување на дефинициите за типови (т.н. никулци) за некои популарни библиотеки со отворен код во централизирано складиште на Python типизиран.

Имплементиравме (и стандардизиравме во следните PEP) нови карактеристики на типовиот систем што овозможува попрецизни типови за некои специфични шаблони на Python. Забележителен пример за ова е TypeDict, кој обезбедува типови за речници слични на JSON кои имаат фиксен сет на копчиња од низа, секој со вредност од свој тип. Ќе продолжиме да го шириме системот на типови. Нашиот следен чекор најверојатно ќе биде да ја подобриме поддршката за нумеричките способности на Python.

Број на линии на означен код: сервер

Број на линии на означен код: клиент

Вкупен број на линии на означен код

Еве преглед на главните карактеристики на работите што ги направивме за да го зголемиме количеството на забележан код во Dropbox:

Строгост на прибелешката. Постепено ги зголемувавме барањата за строгоста на прибележување на нов код. Започнавме со совети за ливчиња кои сугерираа додавање прибелешки на датотеки што веќе имаа некои прибелешки. Сега бараме прибелешки за типови во новите датотеки на Python и во повеќето постоечки датотеки.

Извештаи за пишување. На тимовите им испраќаме неделни извештаи за степенот на внесување на нивниот код и даваме совети за тоа што треба прво да се припише.

Популаризација на mypy. Зборуваме за mypy на настани и разговараме со тимови за да им помогнеме да започнат со прибелешки за типови.

Анкети. Ние спроведуваме периодични анкети на корисниците за да ги идентификуваме главните проблеми. Подготвени сме да одиме доста далеку во решавањето на овие проблеми (дури и создавање нов јазик за забрзување на mypy!).

Изведба. Во голема мера ги подобривме перформансите на mypy со користење на демонот и 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). Пајтон ја отежнува работата со кружни увози, главно поради тоа што изразите се двосмислени. На пример, операцијата за доделување всушност може да дефинира псевдоним од типот. Mypy не може секогаш да открие вакви работи додека не се обработи поголемиот дел од јамката за увоз. Во Алоре немаше такви нејаснотии. Лошите одлуки донесени во раните фази на развојот на системот може да му претставуваат непријатно изненадување на програмерот многу години подоцна.

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

Проектот mypy помина долг пат - од раните прототипови до систем кој контролира 4 милиони линии на типови на кодови за производство. Како што еволуираше mypy, навестувањата за типот на Python беа стандардизирани. Деновиве се разви моќен екосистем околу пишувањето на кодот на Python. Има место за библиотечна поддршка, содржи помошни алатки за IDE и уредници, има неколку системи за контрола на типот, од кои секоја има свои добрите и лошите страни.

Иако проверката на типот е веќе дадена во Dropbox, верувам дека сè уште сме во раните денови на пишување код на Python. Мислам дека технологиите за проверка на типот ќе продолжат да се развиваат и подобруваат.

Ако веќе не сте користеле проверка на типот во вашиот проект од големи размери на Python, тогаш знајте дека сега е многу добро време да започнете да се движите кон статичко пишување. Разговарав со оние кои направија слична транзиција. Никој од нив не зажали. Проверката на типот го прави Python јазик кој е многу посоодветен за развој на големи проекти отколку „обичен Python“.

Почитувани читатели! Дали користите проверка на тип во вашите Python проекти?

Извор: www.habr.com