ProHoster > Blog > Administrazioa > Python kodearen 4 milioi lerro mota egiaztatzeko bidea. 1. zatia

Python kodearen 4 milioi lerro mota egiaztatzeko bidea. 1. zatia

Gaur Dropbox-ek Python kodearen mota-kontrola nola lantzen duen azaltzen duen materialaren itzulpenaren lehen zatia ekarriko dizuegu.

Python kodearen 4 milioi lerro mota egiaztatzeko bidea. 1. zatia

Dropbox-ek asko idazten du Python-en. Oso zabal erabiltzen dugun hizkuntza da, bai back-end zerbitzuetarako, bai mahaigaineko bezero aplikazioetarako. Go, TypeScript eta Rust ere asko erabiltzen ditugu, baina Python da gure hizkuntza nagusia. Gure eskala kontuan hartuta, eta Python kodearen milioika lerroez ari garela, ondorioztatu zen kode horren idazketa dinamikoak ulermena alferrik zaildu zuela eta lanaren produktibitateari larriki eragiten hasi zela. Arazo hau arintzeko, pixkanaka-pixkanaka gure kodea motako egiaztapen estatikora pasatzen hasi gara mypy erabiliz. Hau da ziurrenik Python-en motak egiaztatzeko sistema autonomoena. Mypy kode irekiko proiektu bat da, bere garatzaile nagusiek Dropbox-en lan egiten dute.

Dropbox Python kodean motako egiaztapen estatikoa ezarri zuen lehen enpresetako bat izan zen eskala honetan. Mypy gaur egun milaka proiektutan erabiltzen da. Tresna hau hamaika aldiz, diotenez, "borrokan probatu da". Bide luzea egin dugu orain gauden tokira iristeko. Bidean, arrakastarik gabeko konpromiso eta esperimentu porrot asko izan ziren. Argitalpen honek Python-en tipologia estatikoen egiaztapenaren historia biltzen du, nire ikerketa-proiektuaren parte gisa bere hastapen harritsuetatik, gaur egunera arte, tipoen egiaztapena eta mota-iradokizunak ohiko bihurtu direnean Python-en idazten duten garatzaile ugarientzat. Mekanismo hauek gaur egun tresna askok onartzen dituzte, hala nola, IDEak eta kode analizatzaileak.

β†’ Irakurri bigarren zatia

Zergatik da beharrezkoa mota egiaztatzea?

Inoiz dinamikoki idatzitako Python erabili baduzu, baliteke azkenaldian idazketa estatikoari eta mypyri buruz hainbesteko zalaparta zergatik sortu den jakiteko. Edo agian Python gustatzen zaizu idazketa dinamikoagatik, eta gertatzen ari denak asaldatzen zaitu. Idazketa estatikoen balioaren gakoa soluzioen eskala da: zenbat eta handiagoa izan zure proiektua, orduan eta gehiago makurtzen zara idazketa estatikorantz, eta, azkenean, orduan eta gehiago behar duzu.

Demagun proiektu jakin batek hamarnaka mila lerroren tamaina lortu duela eta hainbat programatzaile lanean ari direla ikusi dela. Antzeko proiektu bati erreparatuz, gure esperientziatik abiatuta, esan dezakegu bere kodea ulertzea gakoa izango dela garatzaileak produktiboa mantentzeko. Motaren oharpenik gabe, zaila izan daiteke asmatzea, adibidez, zer argumentu pasatu behar zaion funtzio bati edo zer motatako funtzioak itzul ditzakeen. Hona hemen motako oharrak erabili gabe erantzutea zaila den galdera tipikoak:

  • Funtzio hau itzuli al daiteke None?
  • Zein izan behar du argudio honek? items?
  • Zein da atributu mota id: int da, str, edo agian mota pertsonalizaturen bat?
  • Argudio honek zerrenda bat izan behar al du? Posible al da hari tupla bat pasatzea?

Mota-anotatutako kode zati hau begiratu eta antzeko galderei erantzuten saiatzen bazara, hauxe da zeregin errazena:

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

  • read_metadata ez da itzultzen None, itzulera mota ez baita Optional[…].
  • Argudioa items lerro-segida bat da. Ezin da ausaz errepikatu.
  • Atributu id byte-kate bat da.

Mundu ideal batean, horrelako Γ±abardura guztiak integratutako dokumentazioan (docstring) deskribatuko liratekeela espero litzateke. Baina esperientziak adibide asko ematen ditu dokumentazio hori askotan lan egin behar duzun kodean ez dela ikusten. Dokumentazio hori kodean badago ere, ezin da bere erabateko zuzentasunarekin zenbatu. Dokumentazio hori lausoa, zehaztugabea eta gaizki-ulertuetara irekia izan daiteke. Talde handietan edo proiektu handietan, arazo hau oso larria izan daiteke.

Python proiektuen hasierako edo erdiko faseetan nabarmentzen den arren, noizbait Python erabiltzen duten proiektu arrakastatsuek eta enpresek ezinbesteko galderari aurre egin dezakete: "Dena berridatzi behar al dugu estatikoki idatzitako hizkuntza batean?".

Mypy bezalako motak egiaztatzeko sistemek goiko arazoa konpontzen dute garatzaileari motak deskribatzeko hizkuntza formal bat eskainiz eta mota-deklarazioak programaren ezarpenarekin bat datozela egiaztatuz (eta, aukeran, haien existentzia egiaztatuz). Orokorrean, sistema hauek arretaz egiaztatutako dokumentazioa bezalako zerbait jartzen dutela gure esku esan dezakegu.

Sistema horien erabilerak beste abantaila batzuk ditu, eta dagoeneko ez dira hutsalak:

  • Mota egiaztatzeko sistemak akats txiki batzuk (eta ez hain txikiak) hauteman ditzake. Adibide tipiko bat balio bat prozesatzea ahazten zaienean da None edo beste baldintza bereziren bat.
  • Kode birfaktorizazioa asko errazten da, mota egiaztatzeko sistema askotan oso zehatza delako zer kodea aldatu behar den. Aldi berean, ez dugu espero behar % 100eko kodeen estaldura probekin, eta hori, nolanahi ere, normalean ez da bideragarria. Ez dugu pilaren arrastoaren sakoneran sakondu behar arazoaren zergatia ezagutzeko.
  • Proiektu handietan ere, mypy-k sarritan mota osoa egiaztatzea segundo baten zati batean egin dezake. Eta proben exekuzioak normalean hamar segundo edo minutu behar ditu. Motak egiaztatzeko sistemak programatzaileari berehalako iritzia ematen dio eta bere lana azkarrago egiteko aukera ematen dio. Jada ez du idatzi behar hauskorrak eta zailak diren unitate-probak mantentzeko benetako entitateak simulak eta adabakiekin ordezkatzen dituzten kode-testen emaitzak azkarrago lortzeko.

PyCharm edo Visual Studio Code bezalako IDEek eta editoreek motako oharpenen boterea erabiltzen dute garatzaileei kodea osatzea, erroreak nabarmentzea eta ohiko hizkuntza-eraikuntzetarako laguntza emateko. Eta hauek idaztearen abantailetako batzuk besterik ez dira. Programatzaile batzuentzat, hori guztia da idazketaren aldeko argudio nagusia. Inplementatu eta berehala onuragarria den zerbait da. Moten erabilera-kasu honek ez du mypy bezalako motak egiaztatzeko sistema bereizirik behar, nahiz eta kontuan izan behar den mypy-k motako oharpenak kodearekin koherente izaten laguntzen duela.

mypy-ren atzeko planoa

Mypyren historia Erresuma Batuan hasi zen, Cambridgen, Dropbox-en sartu baino urte batzuk lehenago. Doktoretza-ikerketaren baitan parte hartu dut lengoaia estatikoki tipifikatu eta dinamikoen bateratzean. Jeremy Siek eta Walid Taha-ren idazketa inkrementalari buruzko artikulu batean eta Typed Racket proiektuan inspiratu nintzen. Hainbat proiektutarako programazio-lengoaia bera erabiltzeko moduak aurkitzen saiatu nintzen - script txikietatik milioika lerroz osatutako kode-oinarrietaraino. Aldi berean, edozein eskalatako proiektu batean konpromiso handiegirik egin beharko ez zela ziurtatu nahi nuen. Honen guztiaren zati garrantzitsu bat idatzi gabeko prototipo-proiektu batetik guztiz probatutako produktu estatikoko amaitu batera pasatzeko ideia izan zen. Egun, ideia hauek neurri handi batean berebizikotzat hartzen dira, baina 2010ean oraindik aktiboki aztertzen ari zen arazoa zen.

Nire jatorrizko lana mota egiaztatzeko ez zegoen Python-i zuzenduta. Horren ordez, "etxeko" hizkuntza txiki bat erabili nuen Alore. Hona hemen zertaz ari garen ulertzen utziko dizun adibide bat (mota oharrak aukerakoak dira hemen):

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

Jatorrizko hizkuntza sinplifikatu bat erabiltzea ikerketa zientifikoetan ohikoa da. Hala da, ez behintzat esperimentuak azkar egiteko aukera ematen duelako, eta azterketarekin zerikusirik ez duena erraz bazter daitekeelako. Mundu errealeko programazio-lengoaiak eskala handiko fenomenoak izan ohi dira inplementazio konplexuekin, eta horrek esperimentazioa moteltzen du. Dena den, hizkuntza sinplifikatu batean oinarritutako edozein emaitza susmagarri samarra dirudi, izan ere, emaitza horiek lortzeko ikertzaileak hizkuntzen erabilera praktikorako garrantzitsuak diren gogoetak sakrifikatu izan ditzakeelako.

Alorerako nire mota egiaztatzaileak oso itxaropentsua iruditu zitzaidan, baina egiazko kodearekin esperimentatuz probatu nahi nuen; Zorionez niretzat, Alore hizkuntza, neurri handi batean, Python-en ideia berdinetan oinarritzen zen. Nahikoa erraza zen mota-zuzentzailea berregitea, Python-en sintaxiarekin eta semantikarekin lan egin ahal izateko. Horri esker, kode irekiko Python kodean idazketa egiaztatzen saiatu ginen. Horrez gain, transpiler bat idatzi nuen Alore-n idatzitako kodea Python kodea bihurtzeko eta nire typechecker kodea itzultzeko erabili nuen. Orain Python-en idatzitako mota egiaztatzeko sistema bat nuen, Python-en azpimultzo bat onartzen zuena, hizkuntza motaren bat! (Alorentzat zentzua zuten zenbait erabaki arkitektoniko ez ziren Pythonentzat oso egokiak, eta hori nabaritzen da oraindik mypy kode-basearen zatietan).

Izan ere, nire tipo-sistemak onartzen duen hizkuntzari ezin zaio guztiz Python deitu une honetan: Python-en aldaera bat zen, Python 3 motako oharpen sintaxiaren muga batzuengatik.

Java eta Python nahasketa bat zirudien:

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

Garai hartan nire ideietako bat motako oharpenak erabiltzea zen errendimendua hobetzeko Python mota hau C-ra, edo agian JVM bytecode konpilatuz. Konpiladore-prototipo bat idazteko fasera iritsi nintzen, baina ideia hori alde batera utzi nuen, mota egiaztatzeak nahiko erabilgarria zirudien.

Santa Klarako PyCon 2013-n nire proiektua aurkezten amaitu nuen. Horretaz ere hitz egin nuen Guido van Rossum-ekin, bizitza osorako Python diktadore onbera. Nire sintaxia kendu eta Python 3 sintaxi estandarrari eusten ninduen konbentzitu ninduen. Python 3-k funtzioen oharpenak onartzen ditu, beraz, nire adibidea behean erakusten den moduan berridatzi liteke, Python programa normal bat sortuz:

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

Konpromiso batzuk egin behar izan nituen (lehenik eta behin, kontuan izan nahi dut arrazoi horregatik asmatu nuela nire sintaxia). Bereziki, Python 3.3-k, garai hartako hizkuntzaren bertsio berriena, ez zuen oharpen aldakorrik onartzen. Guidorekin posta elektroniko bidez eztabaidatu nituen oharpenen diseinu sintaktikorako hainbat aukera. Aldagaietarako iruzkin motak erabiltzea erabaki dugu. Horrek nahi zuen helburua bete zuen, baina astuna izan zen (Python 3.6-k sintaxi politagoa eman zigun):

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

Mota iruzkinak ere erabilgarriak izan dira Python 2 onartzeko, zeinak ez du motako oharpenetarako euskarri integratua:

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

Kontuan izan zen horiek (eta beste) truke-offak ez zirela benetan axola - idazketa estatikoaren onurez erabiltzaileek laster ahaztu zuten sintaxi ez-perfektua. Mota egiaztatutako Python kodean eraikuntza sintaktiko berezirik erabili ez zenez, lehendik zeuden Python tresnek eta kodea prozesatzeko prozesuek normaltasunez funtzionatzen jarraitu zuten, garatzaileei tresna berria ikastea askoz erraztuz.

Guidok ere Dropbox-era sartzeko konbentzitu ninduen gradu-tesia amaitu ondoren. Hor hasten da mypy istorioaren zatirik interesgarriena.

Jarraitu ahal izateko ...

Irakurle maitea! Python erabiltzen baduzu, esan iezaguzu hizkuntza honetan garatzen dituzun proiektuen eskala.

Python kodearen 4 milioi lerro mota egiaztatzeko bidea. 1. zatia
Python kodearen 4 milioi lerro mota egiaztatzeko bidea. 1. zatia

Iturria: www.habr.com

Gehitu iruzkin berria