Wy presintearje jo oandacht it tredde diel fan 'e oersetting fan materiaal oer it paad dat Dropbox naam by it ymplementearjen fan in typekontrôlesysteem foar Python-koade.
→ Foarige dielen: и
It berikken fan 4 miljoen rigels fan typte koade
In oare grutte útdaging (en de twadde meast foarkommende soarch ûnder de yntern ûndersochte) wie it fergrutsjen fan it bedrach fan koade bedekt troch typekontrôles yn Dropbox. Wy hawwe ferskate oanpakken besocht om dit probleem op te lossen, fan natuerlik groeien fan de grutte fan 'e typte koadebase oant it fokusjen fan de ynspanningen fan it mypy-team op statyske en dynamyske automatisearre typekonferinsje. Oan 'e ein like it as wie d'r gjin ienfâldige winnende strategy, mar wy koenen rappe groei berikke yn it folume fan annotearre koade troch in protte oanpak te kombinearjen.
As gefolch hat ús grutste Python-repository (mei backend-koade) hast 4 miljoen rigels fan annotearre koade. It wurk oan statyske koadetypen is yn likernôch trije jier klear. Mypy stipet no ferskate soarten koade-dekkingsrapporten dy't it makliker meitsje om de foarútgong fan typen te kontrolearjen. Yn it bysûnder kinne wy rapporten generearje oer koade mei dûbelsinnigens yn typen, lykas bygelyks eksplisyt gebrûk fan in type Any yn annotaasjes dy't net ferifiearre wurde kinne, of mei saken lykas it ymportearjen fan biblioteken fan tredden dy't gjin type annotaasjes hawwe. As ûnderdiel fan in projekt om de krektens fan typekontrôle yn Dropbox te ferbetterjen, hawwe wy bydroegen oan it ferbetterjen fan de typedefinysjes (saneamde stub-bestannen) foar guon populêre iepen boarne-biblioteken yn in sintralisearre Python-repository .
Wy ymplementearre (en standerdisearre yn folgjende PEPs) nije funksjes fan it type systeem dat tastean mear sekuere typen foar guon spesifike Python patroanen. In opmerklik foarbyld hjirfan is TypeDict, dy't soarten jout foar JSON-lykas wurdboeken dy't in fêste set tekenrige toetsen hawwe, elk mei in wearde fan in eigen type. Wy sille trochgean mei it útwreidzjen fan it type systeem. Us folgjende stap sil wierskynlik wêze om stipe te ferbetterjen foar Python's numerike mooglikheden.
Oantal rigels fan annotearre koade: tsjinner
Oantal rigels fan annotearre koade: client
Totaal oantal rigels fan annotearre koade
Hjir is in oersjoch fan 'e haadfunksjes fan' e dingen dy't wy dien hawwe om it bedrach fan annotearre koade yn Dropbox te ferheegjen:
Annotaasje rigor. Wy fergrutte stadichoan de easken foar de strangens fan it annotearjen fan nije koade. Wy begûnen mei linter tips dy't suggereare annotaasjes ta te foegjen oan bestannen dy't al wat annotaasjes hiene. Wy fereaskje no type annotaasjes yn nije Python-bestannen en yn de measte besteande bestannen.
Typing rapporten. Wy stjoere teams wyklikse rapporten oer it nivo fan typen yn har koade en jouwe advys oer wat earst annotearre wurde moat.
Popularisearring fan mypy. Wy prate oer mypy by eveneminten en prate mei teams om har te helpen te begjinnen mei typeannotaasjes.
Polls. Wy fiere periodike brûkersûndersiken om grutte problemen te identifisearjen. Wy binne ree om frij fier te gean by it oplossen fan dizze problemen (sels in nije taal meitsje om mypy te fersnellen!).
Optreden. Wy hawwe de prestaasjes fan mypy gâns ferbettere troch de daemon en mypyc te brûken. Dit is dien om de ûngemak dy't ûntsteane tidens it annotaasjeproses glêd te meitsjen, en om mei grutte hoemannichten koade te wurkjen.
Yntegraasje mei redakteuren. Wy hawwe ark boud om mypy te stypjen yn bewurkers dy't populêr binne op Dropbox. Dit omfettet PyCharm, Vim en VS Code. Dit ferienfâldige it proses fan it annotearjen fan de koade en it kontrolearjen fan syn funksjonaliteit sterk. Dizze soarten aksjes binne gewoan by it annotearjen fan besteande koade.
Statyske analyze. Wy hawwe in ark makke om funksje-hantekeningen ôf te lieden mei help fan statyske analyse-ark. Dit ark kin allinnich wurkje yn relatyf ienfâldige situaasjes, mar it holp ús te fergrutsjen ús koade type dekking sûnder folle muoite.
Stipe foar biblioteken fan tredden. In protte fan ús projekten brûke de SQLAlchemy toolkit. It profiteart fan 'e dynamyske mooglikheden fan Python dat PEP 484-typen net direkt kinne modelearje. Wy hawwe, yn oerienstimming mei PEP 561, it oerienkommende stubbestân makke en in plugin skreaun foar mypy (), wat SQLAlchemy-stipe ferbettert.
Swierrichheden dy't wy tsjinkamen
It paad nei 4 miljoen rigels fan typte koade hat ús net altyd maklik west. Op dit paad kamen wy in protte potholes tsjin en makken ferskate flaters. Dit binne guon fan 'e problemen dy't wy tsjinkamen. Wy hoopje dat it fertellen oer har oaren sil helpe om ferlykbere problemen te foarkommen.
Untbrekkende triemmen. Wy begon ús wurk troch mar in lyts oantal bestannen te kontrolearjen. Alles dat net opnommen is yn dizze bestannen is net kontrolearre. Bestannen waarden tafoege oan de skennen list doe't de earste annotaasjes ferskynden yn harren. As der wat ymportearre waard fan in module bûten it berik fan ferifikaasje, dan hiene wy it oer wurkjen mei wearden lykas Any, dy't hielendal net hifke waarden. Dit late ta in signifikant ferlies fan typen krektens, benammen yn 'e iere stadia fan migraasje. Dizze oanpak hat oant no ta ferrassend goed wurke, hoewol in typyske situaasje is dat it tafoegjen fan bestannen oan 'e omfang fan' e resinsje problemen ûntbleatet yn oare dielen fan 'e codebase. Yn it slimste gefal, doe't twa isolearre gebieten fan koade waarden gearfoege, dêr't, ûnôfhinklik fan inoar, typen waarden al kontrolearre, it die bliken dat de soarten fan dizze gebieten wiene net kompatibel mei elkoar. Dit late ta de needsaak om in protte wizigingen oan 'e annotaasjes te meitsjen. No weromsjen, realisearje wy dat wy kearnbibleteekmodules earder moatte tafoege hawwe oan it typekontrôlegebiet fan mypy. Dit soe ús wurk folle mear foarsisber meitsje.
Annotearjen fan âlde koade. Doe't wy begûnen, hienen wy sawat 4 miljoen rigels fan besteande Python-koade. It wie dúdlik dat it annotearjen fan al dizze koade gjin maklike taak wie. Wy hawwe in ark makke mei de namme PyAnnotate dat typeynformaasje sammelje kin as testen rinne en typeannotaasjes kinne tafoegje oan jo koade basearre op de sammele ynformaasje. Wy hawwe lykwols net in bysûnder wiidferspraat oannimmen fan dit ark opmurken. It sammeljen fan typeynformaasje wie stadich, en automatysk oanmakke annotaasjes easke faak in protte hânmjittige bewurkings. Wy tochten oer it útfieren fan dit ark automatysk elke kear as wy koade beoardielje, of it sammeljen fan typeynformaasje basearre op it analysearjen fan wat lyts folume fan wirklike netwurkoanfragen, mar besletten dat net te dwaan, om't beide oanpak te riskant wie.
As gefolch kin opmurken wurde dat it grutste part fan 'e koade troch de eigners mei de hân annotearre waard. Om dit proses yn 'e goede rjochting te lieden, meitsje wy rapporten op oer benammen wichtige modules en funksjes dy't moatte wurde annotearre. Bygelyks, it is wichtich om te foarsjen type annotaasjes foar in bibleteek module dat wurdt brûkt yn hûnderten plakken. Mar in âlde tsjinst dy't ferfongen wurdt troch in nije is net mear sa wichtich om te annotearjen. Wy eksperimintearje ek mei it brûken fan statyske analyse om type-annotaasjes te generearjen foar legacy-koade.
Cyclic ymport. Hjirboppe haw ik it oer siklyske ymporten (de "ôfhinklike tangles"), wêrfan it bestean it lestich makke om mypy te fersnellen. Wy moasten ek hurd wurkje om mypy alle soarten idioom te stypjen dy't wurde feroarsake troch dizze syklyske ymporten. Wy hawwe koartlyn in grut systeem werûntwerpprojekt foltôge dat de measte problemen fan mypy oangeande sirkulêre ymporten reparearre. Dizze problemen kamen eins út 'e iere dagen fan it projekt, werom fan Alore, de edukative taal wêrop it mypy-projekt oarspronklik rjochte wie. Alore-syntaksis makket it maklik om problemen op te lossen mei syklyske ymportkommando's. Moderne mypy hat wat beheiningen erfd fan har eardere, ienfâldich-minded ymplemintaasje (dat wie in geweldige fit foar Alore). Python makket wurkjen mei sirkulêre ymporten lestich, benammen om't útdrukkingen dûbelsinnich binne. Bygelyks, in tawizing operaasje kin eins definiearje in type alias. Mypy is net altyd yn steat om dingen lykas dit te ûntdekken oant it grutste part fan 'e ymportlus is ferwurke. D'r wiene gjin sokke ûndúdlikheden yn Alore. Mine besluten makke yn 'e iere stadia fan systeemûntwikkeling kinne in protte jierren letter in onaangename ferrassing foar de programmeur presintearje.
Resultaten: it paad nei 5 miljoen rigels koade en nije horizonten
It mypy-projekt is in lange wei kommen - fan iere prototypen oant in systeem dat 4 miljoen rigels fan produksjekoadetypen kontrolearret. As mypy evoluearre, waarden Python's type hints standerdisearre. Dizze dagen is in krêftich ekosysteem ûntwikkele om Python-koade te typen. It hat in plak foar biblioteekstipe, it befettet helpmiddels foar IDE's en redakteuren, it hat ferskate typekontrôlesystemen, elk fan har hat syn eigen foar- en neidielen.
Sels hoewol typekontrôle al in gegeven is by Dropbox, leau ik dat wy noch yn 'e iere dagen binne fan it typen fan Python-koade. Ik tink dat technologyen foar typekontrôle sille trochgean te ûntwikkeljen en te ferbetterjen.
As jo it typekontrôle net al brûkt hawwe yn jo grutskalige Python-projekt, wit dan dat no in heul goede tiid is om te begjinnen oer te gean nei statysk typen. Ik haw praat mei dyjingen dy't hawwe makke in ferlykbere oergong. Net ien fan harren hie der spyt fan. Typekontrôle makket Python in taal dy't folle better geskikt is foar it ûntwikkeljen fan grutte projekten dan "gewoane Python."
Dear readers! Brûk jo typekontrôle yn jo Python-projekten?
Boarne: www.habr.com