Ons bied u aandag aan die derde deel van die vertaling van materiaal oor die pad waardeur Dropbox gegaan het, en implementeer 'n stelsel om die tipe Python-kode na te gaan.
→ Vorige dele: и
Bereik 4 miljoen reëls van getikte kode
Nog 'n groot uitdaging (en die tweede mees algemene bekommernis vir diegene wat aan interne opnames deelgeneem het) was om die hoeveelheid kode in Dropbox wat deur tipe tjeks gedek word, te verhoog. Ons het verskeie benaderings tot hierdie taak probeer, van die natuurlike groei van die grootte van die getikte kodebasis tot die fokus van mypy-spanlede op statiese en dinamiese outomatiese tipe-afleiding. As gevolg hiervan het dit gelyk of daar geen eenvoudige wenstrategie was nie, maar ons kon vinnige groei in die hoeveelheid geannoteerde kode behaal deur baie benaderings te kombineer.
As gevolg hiervan, in ons grootste Python-bewaarplek (met backend-kode), het die aantal reëls van geannoteerde kode byna 4 miljoen bereik. Die werk aan statiese kodetik is in ongeveer drie jaar uitgevoer. Mypy ondersteun nou verskeie tipes kodedekkingsverslae wat dit makliker maak om tred te hou met tikvordering. Ons kan veral verslag doen oor kode met tipe onduidelikhede, soos eksplisiete gebruik van tipe Any in aantekeninge wat nie geverifieer kan word nie, of met aantekeninge soos derdeparty-biblioteekinvoere wat nie tipe aantekeninge het nie. Ons, as deel van die Dropbox-tipe kontrole akkuraatheidprojek, het bygedra tot die verbetering van tipe definisies (sogenaamde stomplêers) vir sommige gewilde oopbronbiblioteke in 'n gesentraliseerde Python-bewaarplek .
Ons het nuwe kenmerke van die tipe stelsel geïmplementeer (en gestandaardiseer in daaropvolgende PEP's) wat toelaat dat meer presiese tipes vir sommige spesifieke Python-patrone gebruik word. 'n Noemenswaardige voorbeeld hiervan is TypeDict, wat tipes verskaf vir JSON-agtige woordeboeke wat 'n vaste stel stringsleutels het, elk met 'n waarde van sy eie tipe. Ons sal voortgaan om die tipe stelsel uit te brei. Miskien sal ons volgende stap wees om ondersteuning vir Python se nommermanipulasievermoëns te verbeter.
Aantal reëls van geannoteerde kode: bediener
Aantal reëls van geannoteerde kode: kliënt
Totale aantal reëls van geannoteerde kode
Hier is 'n oorsig van die hoofkenmerke van die stappe wat ons gedoen het om die hoeveelheid geannoteerde kode in Dropbox te verhoog:
Erns van annotasie. Ons het die vereistes vir die strengheid van die aantekening van nuwe kode geleidelik verhoog. Ons het begin met linter-wenke wat voorgestel het om aantekeninge by lêers te voeg wat reeds 'n paar aantekeninge het. Ons benodig nou tipe-aantekeninge in nuwe Python-lêers en in die meeste bestaande lêers.
Tik verslae. Ons stuur weeklikse verslae aan spanne oor die vlak van tik van hul kode en gee raad oor wat om eerste te annoteer.
Popularisering van mypy. Ons praat oor mypy by verskeie geleenthede en praat met spanne om hulle te help om aan die gang te kom met die gebruik van tipe-aantekeninge.
Meningspeilings. Ons doen periodieke gebruikersopnames om groot kwessies te identifiseer. Ons is gereed om ver genoeg te gaan om hierdie probleme op te los (selfs tot die punt om 'n nuwe taal te skep om mypy te bespoedig!).
Optrede. Ons het die werkverrigting van mypy aansienlik verbeter deur die gebruik van die daemon en mypyc. Dit is gedoen om die ongerief wat tydens die annotasieproses ontstaan glad te maak, en om met groot hoeveelhede kode te kan werk.
Integrasie met redakteurs. Ons het nutsgoed geskep om mypy te ondersteun in redigeerders wat gewild is by Dropbox. Dit sluit PyCharm-, Vim- en VS-kode in. Dit het die proses om die kode te annoteer en die prestasie daarvan na te gaan, aansienlik vereenvoudig. Sulke aksies is gewoonlik tipies wanneer bestaande kode annoteer word.
Statiese analise. Ons het 'n instrument geskep om funksie-handtekeninge af te lei met behulp van statiese analise-instrumente. Hierdie instrument werk dalk net in relatief eenvoudige situasies, maar dit het ons gehelp om ons kodedekking met tipes sonder veel moeite te vergroot.
Ondersteuning vir derdeparty-biblioteke. Baie van ons projekte gebruik die SQLAlchemy toolkit. Dit maak gebruik van die dinamiese kenmerke van Python dat PEP 484-tipes nie direk kan modelleer nie. Ons het, in ooreenstemming met PEP 561, die ooreenstemmende stomplêer geskep en 'n inprop vir mypy () wat ondersteuning vir SQLAlchemy verbeter.
Die moeilikhede wat ons teëgekom het
Die pad na 4 miljoen reëls getikte kode was nie altyd vir ons maklik nie. Langs die pad het ons baie gate ontmoet en 'n paar foute gemaak. Hier is 'n paar van die probleme wat ons teëgekom het. Ons hoop dat die storie oor hulle ander sal help om soortgelyke probleme te vermy.
Lêers oorgeslaan. Ons het begin deur slegs 'n klein hoeveelheid lêers na te gaan. Enigiets wat nie by hierdie lêers ingesluit is nie, is nie nagegaan nie. Lêers is by die kontrolelys gevoeg toe die eerste aantekeninge daarin verskyn het. As iets ingevoer is vanaf 'n module wat buite die omvang van die tjek geleë is, het dit gegaan oor die werk met waardes van tipe Anywat glad nie getoets is nie. Dit het gelei tot 'n aansienlike verlies aan tik akkuraatheid, veral in die vroeë stadiums van die migrasie. Hierdie benadering het tot dusver merkwaardig goed gewerk, hoewel dit algemeen was dat lêers by die skanderingsarea gevoeg word om probleme in ander dele van die kodebasis te openbaar. In die ergste geval, toe twee geïsoleerde gebiede van kode gekombineer is, waarin, onafhanklik van mekaar, tipes reeds nagegaan is, het dit geblyk dat die tipes van hierdie gebiede nie met mekaar versoenbaar was nie. Dit het gelei tot die behoefte om baie veranderinge aan die aantekeninge aan te bring. As ons nou terugkyk, besef ons dat ons so vroeg as moontlik kernbiblioteekmodules by mypy se tipe-kontrole-omvang moes gevoeg het. Dit sal ons werk baie meer voorspelbaar maak.
Annoteer ou kode. Toe ons begin het, het ons ongeveer 4 miljoen reëls bestaande Python-kode gehad. Dit was duidelik dat dit geen maklike taak was om al hierdie kode te annoteer nie. Ons het 'n instrument genaamd PyAnnotate geskep wat tipe inligting kan versamel tydens toetsuitvoering en tipe annotasies kan byvoeg by kode gebaseer op die inligting wat ingesamel is. Ons het egter nie 'n besonder wye implementering van hierdie instrument opgemerk nie. Die insameling van tipe inligting was stadig, en outo-gegenereerde aantekeninge het dikwels baie handmatige wysigings vereis. Ons het daaraan gedink om hierdie nutsding outomaties op elke kodekontrole te laat loop, of om tipe inligting in te samel gebaseer op 'n klein hoeveelheid werklike netwerkversoeke, maar het besluit om dit nie te doen nie, want een van die benaderings is te riskant.
As gevolg hiervan kan opgemerk word dat die meeste van die kode handmatig deur sy eienaars geannoteer is. Ons, om hierdie proses in die regte rigting te rig, berei verslae voor oor veral belangrike modules en funksies wat geannoteer moet word. Byvoorbeeld, dit is belangrik om 'n biblioteekmodule wat op honderde plekke gebruik word, te annoteer. Maar die ou diens, wat deur 'n nuwe een vervang word, is nie meer so belangrik om te annoteer nie. Ons eksperimenteer ook met die gebruik van statiese analise om tipe-aantekeninge vir verouderde kode te genereer.
Sikliese invoere. Hierbo het ek gepraat van omsendbrief invoere (oor "tangles of dependencies"), waarvan die bestaan dit moeilik gemaak het vir mypy om te versnel. Ons moes ook hard werk om mypy alle soorte idiome te laat ondersteun wat hierdie omsendbrief invoere veroorsaak. Ons het onlangs 'n groot stelselherontwerp voltooi wat die meeste van mypy se probleme met omsendbriefinvoere opgelos het. Hierdie probleme het eintlik gespruit uit die baie vroeë dae van die projek, terug van Alore, die onderrigtaal waarop die mypy-projek oorspronklik gefokus was. Die Alore-sintaksis maak dit maklik om die probleme van sikliese invoeropdragte op te los. Moderne mypy het sommige van die beperkings van sy vroeë, naïewe implementering geërf (wat wonderlik was vir Alore). Python maak dit moeilik om met sirkulêre invoere te werk, hoofsaaklik as gevolg van die dubbelsinnigheid van uitdrukkings. Byvoorbeeld, 'n opdragbewerking kan eintlik 'n tipe alias definieer. Mypy is nie altyd in staat om dinge soos hierdie op te spoor totdat die meeste van die invoerlus verwerk is nie. Daar was nie sulke onduidelikhede in Alore nie. Swak besluite wat in die vroeë stadiums van stelselontwikkeling geneem word, kan die programmeerder baie jare later 'n onaangename verrassing gee.
Resultate: die pad na 5 miljoen reëls kode en na nuwe horisonne
Die mypy-projek het 'n lang pad gekom van vroeë prototipes tot 'n tipebeheerstelsel vir 4 miljoen reëls produksiekode. Soos mypy ontwikkel het, is Python se tipe aanduiding gestandaardiseer. 'n Kragtige ekosisteem het deesdae ontwikkel rondom die tik van Python-kode. Dit het 'n plek gevind vir biblioteekondersteuning, dit het helpers vir IDE's en redakteurs, dit het verskeie tipe beheerstelsels, wat elkeen sy voor- en nadele het.
Terwyl tipe nagaan reeds as vanselfsprekend by Dropbox aanvaar word, is ek seker ons is nog in die vroeë dae van Python-kode-tik. Ek dink tipe kontrole tegnologie sal voortgaan om te ontwikkel en te verbeter.
As jy nog nie tipe kontrolering in jou grootskaalse Python-projek gebruik het nie, weet dan dat dit nou 'n baie goeie tyd is om na statiese tik te begin beweeg. Ek het met diegene gepraat wat hierdie oorgang gemaak het. Nie een van hulle was spyt daaroor nie. Tipe-kontrolering maak Python 'n baie beter taal as "plain Python" vir die ontwikkeling van groot projekte.
Beste lesers! Gebruik jy tipe kontrolering in jou Python-projekte?
Bron: will.com