Пут до провере типова 4 милиона линија Питхон кода. Део 1

Данас вам представљамо први део превода материјала о томе како се Дропбок бави контролом типова Питхон кода.

Дропбок пише много у Питхон-у. То је језик који користимо изузетно широко, како за позадинске услуге тако и за десктоп клијентске апликације. Такође много користимо Го, ТипеСцрипт и Руст, али Питхон је наш главни језик. С обзиром на наше размере, а реч је о милионима линија Питхон кода, показало се да је динамичко куцање таквог кода непотребно закомпликовало његово разумевање и почело озбиљно да утиче на продуктивност рада. Да бисмо ублажили овај проблем, почели смо да постепено прелазимо наш код на статичку проверу типа користећи мипи. Ово је вероватно најпопуларнији самостални систем за проверу типа за Питхон. Мипи је пројекат отвореног кода, његови главни програмери раде у Дропбок-у.

Дропбок је била једна од првих компанија која је имплементирала статичку проверу типа у Питхон коду на овом нивоу. Мипи се ових дана користи у хиљадама пројеката. Овај алат је безброј пута, како кажу, "тестиран у борби". Прешли смо дуг пут да стигнемо тамо где смо сада. На том путу било је много неуспешних подухвата и неуспешних експеримената. Овај пост покрива историју статичке провере типова у Питхон-у, од његових камених почетака као дела мог истраживачког пројекта, до данас, када су провера типа и наговештавање типова постали уобичајени за безброј програмера који пишу у Питхон-у. Ове механизме сада подржавају многи алати као што су ИДЕ и анализатори кода.

→ Прочитајте други део

Зашто је провера типа неопходна?

Ако сте икада користили динамички куцани Питхон, можда ћете имати забуну зашто се у последње време дигла толика гужва око статичког куцања и мипи-ја. Или можда волите Питхон управо због његовог динамичког куцања, а ово што се дешава вас једноставно узнемири. Кључ вредности статичког куцања је обим решења: што је ваш пројекат већи, више се нагињете статичком куцању, и на крају, то вам је више потребно.

Претпоставимо да је одређени пројекат достигао величину десетина хиљада линија, а испоставило се да на њему ради неколико програмера. Гледајући сличан пројекат, на основу нашег искуства, можемо рећи да ће разумевање његовог кода бити кључ за одржавање продуктивности програмера. Без напомена типа, може бити тешко схватити, на пример, које аргументе треба проследити функцији или које типове функција може да врати. Ево типичних питања на која је често тешко одговорити без употребе напомена о типу:

• Може ли се ова функција вратити None?
• Шта би требало да буде овај аргумент? items?
• Који је тип атрибута id: int Ја седим, str, или можда неки прилагођени тип?
• Да ли овај аргумент треба да буде листа? Да ли је могуће пренети тупле на њега?

Ако погледате следећи исечак кода са коментарима и покушате да одговорите на слична питања, испоставиће се да је ово најједноставнији задатак:

class Resource:
    id: bytes
    ...
    def read_metadata(self, 
                      items: Sequence[str]) -> Dict[str, MetadataItem]:
        ...

• read_metadata не враћа се None, пошто тип враћања није Optional[…].
• Расправа items је низ линија. Не може се насумично понављати.
• Атрибут id је низ бајтова.

У идеалном свету, очекивало би се да ће све такве суптилности бити описане у уграђеној документацији (доцстринг). Али искуство даје много примера да се таква документација често не поштује у коду са којим морате да радите. Чак и ако таква документација постоји у коду, не може се рачунати на његову апсолутну исправност. Ова документација може бити нејасна, нетачна и отворена за неспоразуме. У великим тимовима или великим пројектима, овај проблем може постати изузетно акутан.

Док се Питхон истиче у раним или средњим фазама пројеката, у неком тренутку успешни пројекти и компаније које користе Питхон могу се суочити са виталним питањем: „Да ли треба да препишемо све на статички откуцаном језику?“.

Системи за проверу типова као што је мипи решавају горњи проблем обезбеђујући програмеру формални језик за описивање типова и провером да ли декларације типа одговарају имплементацији програма (и, опционо, провером њиховог постојања). Генерално, можемо рећи да су нам ови системи ставили на располагање нешто попут пажљиво проверене документације.

Употреба таквих система има и друге предности, а оне су већ потпуно нетривијалне:

• Систем за проверу типа може открити неке мале (и не тако мале) грешке. Типичан пример је када забораве да обрађују вредност None или неки други посебан услов.
• Рефакторисање кода је у великој мери поједностављено јер је систем провере типа често веома прецизан о томе који код треба да се промени. У исто време, не треба да се надамо 100% покривености кода тестовима, што, у сваком случају, обично није изводљиво. Не морамо да улазимо у дубину праћења стека да бисмо открили узрок проблема.
• Чак и на великим пројектима, мипи често може да изврши пуну проверу типа у делићу секунде. А извођење тестова обично траје десетине секунди или чак минута. Систем за проверу типа даје програмеру тренутну повратну информацију и омогућава му да брже ради свој посао. Он више не мора да пише крхке и тешке за одржавање јединичних тестова који замењују стварне ентитете имитацијама и закрпама само да би брже добио резултате тестова кода.

ИДЕ и уређивачи као што су ПиЦхарм или Висуал Студио Цоде користе моћ напомена типа да би програмерима пружили довршавање кода, истицање грешака и подршку за најчешће коришћене језичке конструкције. А ово су само неке од предности куцања. За неке програмере, све је ово главни аргумент у корист куцања. Ово је нешто што користи одмах након имплементације. Овај случај употребе за типове не захтева посебан систем за проверу типа као што је мипи, иако треба напоменути да мипи помаже да се напомене типа одржавају у складу са кодом.

Позадина мипи

Историја мипи-ја почела је у Великој Британији, у Кембриџу, неколико година пре него што сам се придружио Дропбок-у. Бавио сам се, у оквиру свог докторског истраживања, обједињавањем статички куцаних и динамичких језика. Инспирисао ме је чланак о инкременталном куцању Џеремија Сика и Валида Тахе и пројекат Типед Рацкет. Покушао сам да пронађем начине да користим исти програмски језик за различите пројекте – од малих скрипти до база кода које се састоје од много милиона линија. Истовремено, желео сам да обезбедим да се у пројекту било ког обима неће правити превелики компромиси. Важан део свега овога била је идеја о постепеном преласку са нетипизираног прототипа пројекта на свеобухватно тестиран статички откуцани готов производ. Ових дана се ове идеје углавном узимају здраво за готово, али 2010. је то био проблем који се још увек активно истражује.

Мој оригинални рад у контроли типа није био усмерен на Питхон. Уместо тога, користио сам мали „домаћи“ језик Алоре. Ево примера који ће вам омогућити да разумете о чему говоримо (напомене типа овде су опционе):

def Fib(n as Int) as Int
  if n <= 1
    return n
  else
    return Fib(n - 1) + Fib(n - 2)
  end
end

Коришћење поједностављеног матерњег језика је уобичајен приступ који се користи у научним истраживањима. То је тако, не само зато што вам омогућава брзо спровођење експеримената, а такође и због чињенице да се оно што нема никакве везе са студијом може лако занемарити. Програмски језици из стварног света обично су феномени великих размера са сложеним имплементацијама, а то успорава експериментисање. Међутим, било који резултати засновани на поједностављеном језику изгледају помало сумњиво, пошто је у добијању ових резултата истраживач можда жртвовао разматрања важна за практичну употребу језика.

Мој уређај за проверу типа за Алоре је изгледао веома обећавајуће, али желео сам да га тестирам експериментишући са правим кодом, који, можете рећи, није написан у Алореу. На моју срећу, језик Алоре је углавном био заснован на истим идејама као и Питхон. Било је довољно лако преправити проверу типова тако да може да ради са Питхон-овом синтаксом и семантиком. Ово нам је омогућило да покушамо да проверимо тип у Питхон коду отвореног кода. Поред тога, написао сам транспилер за претварање кода написаног у Алоре у Питхон код и користио га за превођење кода за проверу типова. Сада сам имао систем за проверу типа написан у Питхон-у који је подржавао подскуп Питхон-а, неку врсту тог језика! (Одређене архитектонске одлуке које су имале смисла за Алоре биле су лоше прикладне за Питхон, а то је још увек приметно у деловима мипи кодне базе.)

У ствари, језик који подржава мој систем типова се у овом тренутку не би могао назвати Питхон: то је била варијанта Питхон-а због неких ограничења синтаксе напомена типа Питхон 3.

Изгледало је као мешавина Јава и Питхон-а:

int fib(int n):
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

Једна од мојих идеја у то време била је да користим напомене типа за побољшање перформанси компајлирањем ове врсте Питхон-а у Ц, или можда ЈВМ бајткод. Дошао сам до фазе писања прототипа компајлера, али сам напустио ову идеју, пошто је сама провера типа изгледала прилично корисно.

На крају сам представио свој пројекат на ПиЦон 2013 у Санта Клари. О томе сам разговарао и са Гвидом ван Росумом, доживотним доброћудним пајтонским диктатором. Убедио ме је да одбацим сопствену синтаксу и да се држим стандардне Питхон 3 синтаксе. Питхон 3 подржава напомене функција, тако да би мој пример могао да се препише као што је приказано испод, што резултира нормалним Питхон програмом:

def fib(n: int) -> int:
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

Морао сам да направим неке компромисе (пре свега, желим да напоменем да сам измислио сопствену синтаксу управо из тог разлога). Конкретно, Питхон 3.3, најновија верзија језика у то време, није подржавао променљиве напомене. Разговарао сам са Гвидом путем е-поште о разним могућностима синтаксичког дизајна таквих напомена. Одлучили смо да користимо коментаре типа за променљиве. Ово је служило предвиђеној сврси, али је било помало гломазно (Питхон 3.6 нам је дао лепшу синтаксу):

products = []  # type: List[str]  # Eww

Коментари типа су такође били корисни да подрже Питхон 2, који нема уграђену подршку за напомене о типу:

f fib(n):
    # type: (int) -> int
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

Испоставило се да ови (и други) компромиси нису били битни – предности статичког куцања значиле су да су корисници убрзо заборавили на мање од савршену синтаксу. Пошто нису коришћене посебне синтаксичке конструкције у Питхон коду са провером типа, постојећи Питхон алати и процеси обраде кода наставили су да раде нормално, што је програмерима много олакшало да науче нови алат.

Гвидо ме је такође убедио да се придружим Дропбок-у након што сам завршио дипломски рад. Овде почиње најзанимљивији део приче о мипи.

Наставиће се ...

Драги читаоци! Ако користите Питхон, реците нам о обиму пројеката које развијате на овом језику.

Извор: ввв.хабр.цом