අද අපි ප්‍රකාශනය කරන්නේ Dropbox විසින් Python කේත පේළි මිලියන කිහිපයක් සඳහා ටයිප් පාලනය සංවිධානය කළ ආකාරය පිළිබඳ තොරතුරු පරිවර්තනයේ දෙවන කොටසයි.
→
නිල ආකාරයේ සහාය (PEP 484)
අපි 2014 Hack Week තුළ Dropbox හිදී mypy සමඟ අපගේ පළමු බරපතල අත්හදා බැලීම් සිදු කළෙමු. Hack Week යනු Dropbox විසින් සත්කාරකත්වය දරන සතියක සිදුවීමකි. මෙම කාලය තුළ, සේවකයින්ට තමන්ට අවශ්ය ඕනෑම දෙයක් මත වැඩ කළ හැකිය! Dropbox හි වඩාත් ප්‍රසිද්ධ තාක්ෂණික ව්‍යාපෘති සමහරක් මෙවැනි සිදුවීම් වලින් ආරම්භ විය. මෙම අත්හදා බැලීමේ ප්‍රතිඵලයක් ලෙස, ව්‍යාපෘතිය තවමත් පුළුල් භාවිතය සඳහා සූදානම් නැති නමුත්, mypy බලාපොරොත්තු සහගත බව අපි නිගමනය කළෙමු.
එකල, පයිතන් වර්ගයේ ඉඟි පද්ධති ප්‍රමිතිගත කිරීමේ අදහස වාතයේ විය. මම කී පරිදි, Python 3.0 සිට ශ්‍රිත සඳහා වර්ග විවරණ භාවිතා කළ හැකි නමුත්, මේවා නිර්වචනය කළ වාක්‍ය ඛණ්ඩ සහ අර්ථ දැක්වීම් නොමැතිව අත්තනෝමතික ප්‍රකාශන පමණි. වැඩසටහන් ක්රියාත්මක කිරීමේදී, මෙම විවරණ බොහෝ දුරට නොසලකා හරින ලදී. හැක් සතියෙන් පසු, අපි අර්ථ ශාස්ත්‍ර ප්‍රමිතිකරණය කිරීමේ වැඩ ආරම්භ කළෙමු. මෙම කාර්යය මතුවීමට හේතු විය (Guido van Rossum, Łukasz Langa සහ මම මෙම ලේඛනය සඳහා සහයෝගයෙන් කටයුතු කළෙමු).
අපේ චේතනාවන් දෙපැත්තකින් බලන්න පුළුවන්. පළමුව, අපි බලාපොරොත්තු වූයේ සමස්ත පයිතන් පරිසර පද්ධතියම වර්ග ඉඟි භාවිතා කිරීම සඳහා පොදු ප්‍රවේශයක් අනුගමනය කළ හැකි බවයි (පයිතන් හි "වර්ග විවරණ" වලට සමාන පදයක් ලෙස භාවිතා කරයි). මෙය, විය හැකි අවදානම් අනුව, බොහෝ අන්‍යෝන්‍ය නොගැලපෙන ප්‍රවේශයන් භාවිතා කිරීමට වඩා හොඳ වනු ඇත. දෙවනුව, අපට අවශ්ය වූයේ පයිතන් ප්‍රජාවේ බොහෝ සාමාජිකයින් සමඟ වර්ග විවරණ යාන්ත්‍රණ විවෘතව සාකච්ඡා කිරීමට ය. පයිතන් ක්‍රමලේඛකයන්ගේ පුළුල් මහජනතාවගේ ඇස් හමුවේ භාෂාවේ මූලික අදහස් වලින් “ඇදහිල්ල අත්හළවුන්” ලෙස පෙනෙන්නට අපට අවශ්ය නොවන බව මෙම ආශාව අර්ධ වශයෙන් නියම කරන ලදී. එය ගතිකව ටයිප් කරන ලද භාෂාවක් වන අතර එය "තාරා ටයිප් කිරීම" ලෙස හැඳින්වේ. ප්‍රජාව තුළ, ආරම්භයේදීම, ස්ථිතික ටයිප් කිරීමේ අදහස කෙරෙහි තරමක් සැක සහිත ආකල්පයක් පැන නැගීමට උදව් කළ නොහැක. නමුත් ස්ථිතික ටයිප් කිරීම අනිවාර්ය නොවන බව පැහැදිලි වූ පසු (සහ එය ඇත්ත වශයෙන්ම ප්‍රයෝජනවත් බව මිනිසුන්ට වැටහුණු පසු) එම හැඟීම අවසානයේ අඩු විය.
අවසානයේ භාවිතා කරන ලද ඉඟි වාක්‍ය ඛණ්ඩය එකල mypy සහාය දුන් දෙයට බෙහෙවින් සමාන විය. PEP 484 3.5 දී Python 2015 සමඟ නිකුත් කරන ලදී. Python තවදුරටත් ගතිකව ටයිප් කළ භාෂාවක් නොවීය. මෙම සිදුවීම පයිතන් ඉතිහාසයේ සුවිශේෂී සන්ධිස්ථානයක් ලෙස මම සිතන්නට කැමැත්තෙමි.
සංක්රමණයේ ආරම්භය
2015 අවසානයේ Dropbox විසින් mypy මත වැඩ කිරීමට තිදෙනෙකුගෙන් යුත් කණ්ඩායමක් නිර්මාණය කරන ලදී. ඔවුන්ට Guido van Rossum, Greg Price සහ David Fisher ඇතුළත් විය. එම මොහොතේ සිට තත්වය ඉතා වේගයෙන් වර්ධනය වීමට පටන් ගත්තේය. mypy වර්ධනයට පළමු බාධාව වූයේ කාර්ය සාධනයයි. මම ඉහත ඉඟි කළ පරිදි, ව්‍යාපෘතියේ මුල් දිනවල මම mypy ක්රියාත්මක කිරීම C බවට පරිවර්තනය කිරීමට සිතුවෙමි, නමුත් මෙම අදහස දැනට ලැයිස්තුවෙන් බැහැර කර ඇත. mypy වැනි මෙවලම් සඳහා ප්‍රමාණවත් තරම් වේගවත් නොවන CPython පරිවර්තකය භාවිතයෙන් පද්ධතිය ක්රියාත්මක කිරීමේදී අපි සිරවී සිටිමු. (JIT සම්පාදකයක් සමඟ විකල්ප Python ක්රියාත්මක කිරීමක් වන PyPy ව්‍යාපෘතිය ද අපට උදව් කළේ නැත.)
වාසනාවකට මෙන්, සමහර ඇල්ගොරිතම වැඩිදියුණු කිරීම් මෙහි අපගේ ආධාරයට පැමිණ ඇත. පළමු බලවත් "ත්වරකය" වර්ධක පරීක්ෂාව ක්රියාත්මක කිරීමයි. මෙම වැඩිදියුණු කිරීම පිටුපස ඇති අදහස සරල විය: mypy හි පෙර ධාවනයේ සිට සියලුම මොඩියුලයේ පරායත්තතා වෙනස් වී නොමැති නම්, අපට පරායත්තතා සමඟ වැඩ කරන අතරතුර පෙර ධාවනයේදී හැඹිලිගත දත්ත භාවිතා කළ හැකිය. අපට අවශ්ය වූයේ වෙනස් කරන ලද ගොනු සහ ඒවා මත රඳා පවතින ලිපිගොනු පිළිබඳ අකුරු පරීක්ෂා කිරීම පමණි. Mypy තව ටිකක් ඉදිරියට ගියා: මොඩියුලයක බාහිර අතුරුමුහුණත වෙනස් නොවන්නේ නම්, mypy උපකල්පනය කළේ මෙම මොඩියුලය ආනයනය කළ අනෙකුත් මොඩියුල නැවත පරීක්ෂා කිරීමට අවශ්ය නොවන බවයි.
පවතින කේත විශාල ප්‍රමාණයක් සටහන් කිරීමේදී වර්ධක පරීක්ෂාව අපට බොහෝ සෙයින් උපකාරී වී ඇත. කාරණය නම්, මෙම ක්‍රියාවලිය සාමාන්යයෙන් මයිපී හි බොහෝ පුනරාවර්තන ධාවනයන් ඇතුළත් වන අතර, ක්‍රමයෙන් විවරණ කේතයට එකතු කර ක්‍රමයෙන් වැඩිදියුණු වේ. mypy හි පළමු ධාවනය තවමත් ඉතා මන්දගාමී වූයේ එයට පරීක්ෂා කිරීමට බොහෝ පරායත්තතා තිබූ බැවිනි. පසුව, තත්වය වැඩිදියුණු කිරීම සඳහා, අපි දුරස්ථ හැඹිලි යාන්ත්රණයක් ක්රියාත්මක කළා. දේශීය හැඹිලිය යල් පැන ගිය බව mypy අනාවරණය කරන්නේ නම්, එය මධ්‍යගත ගබඩාවෙන් සම්පූර්ණ කේත පදනම සඳහා වත්මන් හැඹිලි ස්නැප්ෂොට් බාගත කරයි. එය පසුව මෙම ස්නැප්ෂොට් භාවිතයෙන් වර්ධක පරීක්ෂාවක් සිදු කරයි. මෙය mypy හි කාර්ය සාධනය වැඩි කිරීම සඳහා තවත් විශාල පියවරක් ගෙන ඇත.
මෙය ඩ්‍රොප්බොක්ස් හි වර්ග පිරික්සීම වේගවත් හා ස්වභාවිකව අනුගමනය කළ කාල පරිච්ඡේදයකි. 2016 අවසානය වන විට, අපි දැනටමත් දළ වශයෙන් 420000 ක පයිතන් කේත වර්ග විවරණ සහිත රේඛා ඇත. බොහෝ පරිශීලකයින් වර්ග පරීක්ෂා කිරීම ගැන උනන්දු විය. වැඩි වැඩියෙන් සංවර්ධන කණ්ඩායම් Dropbox mypy භාවිතා කරමින් සිටියහ.
එදා හැමදෙයක්ම හොඳට පෙනුණත් අපිට තව කරන්න ගොඩක් දේවල් තිබුණා. ව්‍යාපෘතියේ ගැටළු සහිත ප්‍රදේශ හඳුනා ගැනීම සහ පළමුව විසඳිය යුතු ගැටළු මොනවාද යන්න තේරුම් ගැනීම සඳහා අපි වරින් වර අභ්‍යන්තර පරිශීලක සමීක්ෂණ සිදු කිරීමට පටන් ගත්තෙමු (මෙම භාවිතය අදටත් සමාගම තුළ භාවිතා වේ). වඩාත්ම වැදගත්, එය පැහැදිලි වූ පරිදි, කාර්යයන් දෙකක් විය. පළමුව, අපට කේතයේ තවත් ආකාරයේ ආවරණයක් අවශ්ය විය, දෙවනුව, අපට වේගයෙන් ක්‍රියා කිරීමට mypy අවශ්ය විය. mypy වේගවත් කිරීම සහ සමාගම් ව්‍යාපෘති බවට එය ක්රියාත්මක කිරීමේ අපගේ කාර්යය තවමත් අවසන් වී නොමැති බව සම්පූර්ණයෙන්ම පැහැදිලි විය. මෙම කාර්යයන් දෙකෙහි වැදගත්කම පිළිබඳව අපි සම්පූර්ණයෙන්ම දැනුවත්ව, ඒවා විසඳීමට සූදානම් වෙමු.
වැඩි ඵලදායිතාවක්!
වර්ධක පරීක්ෂා කිරීම් mypy වේගවත් කළ නමුත් මෙවලම තවමත් ප්‍රමාණවත් තරම් වේගවත් නොවීය. බොහෝ වර්ධක චෙක්පත් විනාඩියක් පමණ පැවතුනි. මෙයට හේතුව චක්‍රීය ආනයනයයි. Python හි ලියා ඇති විශාල කේත සමුදායන් සමඟ වැඩ කර ඇති කිසිවෙකු මෙය පුදුමයට පත් නොවනු ඇත. අප සතුව මොඩියුල සිය ගණනක කට්ටල තිබූ අතර, ඒ සෑම එකක්ම අනෙක් සියල්ල වක්‍රව ආනයනය කරන ලදී. ආයාත ලූපයක ඇති කිසියම් ගොනුවක් වෙනස් කර ඇත්නම්, mypy හට එම ලූපයේ ඇති සියලුම ගොනු සැකසීමට සිදු විය, සහ බොහෝ විට එම ලූපයෙන් මොඩියුල ආනයනය කරන ඕනෑම මොඩියුලයක්. එවැනි එක් චක්‍රයක් වූයේ Dropbox හි බොහෝ කරදර ඇති කළ කුප්‍රකට "යැපුම් පටලැවිල්ල" ය. මෙම ව්‍යුහය මොඩියුල සිය ගණනක් අඩංගු වූ පසු, එය ආනයනය කරන විට, සෘජුව හෝ වක්‍රව, බොහෝ පරීක්ෂණ, එය නිෂ්පාදන කේතයේ ද භාවිතා විය.
අපි චක්‍රලේඛ පරායත්තතා "නොගැලපෙන" හැකියාව සලකා බැලුවෙමු, නමුත් එය කිරීමට අපට සම්පත් නොතිබුණි. අපිට හුරු නැති කේත ඕනෑවට වඩා තිබුණා. එහි ප්‍රතිඵලයක් ලෙස අපි විකල්ප ප්‍රවේශයක් ඉදිරිපත් කළා. "යැපුම් පටලැවිලි" තිබියදීත් mypy ඉක්මනින් වැඩ කිරීමට අපි තීරණය කළෙමු. අපි mypy deemon භාවිතයෙන් මෙම ඉලක්කය සපුරා ගත්තෙමු. ඩීමන් යනු රසවත් හැකියාවන් දෙකක් ක්රියාත්මක කරන සේවාදායක ක්‍රියාවලියකි. පළමුව, එය සම්පූර්ණ කේත පදනම පිළිබඳ තොරතුරු මතකයේ ගබඩා කරයි. මෙයින් අදහස් කරන්නේ ඔබ mypy ධාවනය කරන සෑම අවස්ථාවකම, ආනයනික පරායත්තතා දහස් ගණනකට අදාළ හැඹිලිගත දත්ත පූරණය කිරීමට අවශ්ය නොවන බවයි. දෙවනුව, ඔහු ප්රවේශමෙන්, කුඩා ව්යුහාත්මක ඒකක මට්ටමින්, කාර්යයන් සහ අනෙකුත් ආයතන අතර පරායත්තතා විශ්ලේෂණය කරයි. උදාහරණයක් ලෙස, කාර්යය නම් foo ශ්‍රිතයක් කැඳවයි bar, එවිට යැපීම පවතී foo от bar. ගොනුවක් වෙනස් වූ විට, ඩීමන් පළමුව, හුදකලාව, වෙනස් කළ ගොනුව පමණක් සකසයි. එය පසුව එම ගොනුවේ වෙනස් වූ ශ්‍රිත අත්සන් වැනි බාහිරව පෙනෙන වෙනස්කම් දෙස බලයි. ඩීමන් ආයාත කිරීම් පිළිබඳ සවිස්තරාත්මක තොරතුරු භාවිතා කරන්නේ සැබවින්ම වෙනස් කරන ලද ශ්‍රිතය භාවිතා කරන කාර්යයන් දෙවරක් පරීක්ෂා කිරීමට පමණි. සාමාන්යයෙන්, මෙම ප්රවේශය සමඟ, ඔබ ඉතා සුළු කාර්යයන් පරීක්ෂා කළ යුතුය.
මේ සියල්ල ක්රියාත්මක කිරීම පහසු වූයේ නැත, මන්ද මුල් mypy ක්රියාත්මක කිරීම එකවර ගොනුවක් සැකසීම කෙරෙහි දැඩි අවධානයක් යොමු කළ බැවිනි. අපට බොහෝ දේශසීමා තත්වයන් සමඟ කටයුතු කිරීමට සිදු විය, කේතයේ යමක් වෙනස් වූ අවස්ථා වලදී නැවත නැවත පරීක්ෂා කිරීම අවශ්ය වේ. උදාහරණයක් ලෙස, මෙය සිදු වන්නේ පන්තියකට නව මූලික පන්තියක් පැවරූ විටය. අපට අවශ්ය දේ කළ පසු, බොහෝ වර්ධක චෙක්පත් ක්රියාත්මක කිරීමේ කාලය තත්පර කිහිපයකට අඩු කිරීමට අපට හැකි විය. මෙය අපට විශාල ජයග්‍රහණයක් ලෙස පෙනුණි.
ඊටත් වඩා ඵලදායිතාව!
මා ඉහත සාකච්ඡා කළ දුරස්ථ හැඹිලිය සමඟින්, mypy ඩීමන් විසින් ක්‍රමලේඛකයෙකු නිතර ටයිප් චෙක් කිරීම ක්රියාත්මක කරන විට, ලිපිගොනු කුඩා සංඛ්‍යාවක වෙනස්කම් සිදු කරන විට ඇතිවන ගැටළු සම්පූර්ණයෙන්ම පාහේ විසඳා ඇත. කෙසේ වෙතත්, අවම වශයෙන් හිතකර භාවිතයේ දී පද්ධතියේ ක්‍රියාකාරීත්වය තවමත් ප්‍රශස්ත මට්ටමක නොතිබුණි. mypy පිරිසිදු ආරම්භයක් විනාඩි 15කට වඩා ගත විය හැක. ඒ වගේම මේක අපි සතුටු වෙනවාට වඩා වැඩි දෙයක්. සෑම සතියකම ක්‍රමලේඛකයින් නව කේත ලිවීම සහ පවතින කේතයට අනුසටහන් එකතු කිරීම නිසා තත්වය වඩාත් නරක අතට හැරුණි. අපගේ පරිශීලකයින් වැඩි කාර්ය සාධනයක් සඳහා තවමත් කුසගින්නෙන් සිටි නමුත් අතරමගදී ඔවුන් හමුවීම ගැන අපි සතුටු වෙමු.
අපි mypy සම්බන්ධයෙන් පෙර තිබූ එක් අදහසක් වෙත ආපසු යාමට තීරණය කළෙමු. එනම්, පයිතන් කේතය C කේතය බවට පරිවර්තනය කිරීම. Cython සමඟ අත්හදා බැලීම (පයිතන් හි ලියා ඇති කේතය C කේතයට පරිවර්තනය කිරීමට ඔබට ඉඩ සලසන පද්ධතියක්) අපට දෘශ්‍යමාන වේගයක් ලබා නොදුන් නිසා අපි අපේම සම්පාදකයක් ලිවීමේ අදහස නැවත පණ ගැන්වීමට තීරණය කළෙමු. mypy codebase (Python හි ලියා ඇත) දැනටමත් අවශ්ය සියලුම ආකාරයේ අනුසටහන් අඩංගු බැවින්, පද්ධතිය වේගවත් කිරීම සඳහා මෙම අනුසටහන් භාවිතා කිරීමට උත්සාහ කිරීම වටී යැයි අපි සිතුවෙමු. මෙම අදහස පරීක්ෂා කිරීමට මම ඉක්මනින් මූලාකෘතියක් නිර්මාණය කළෙමි. එය විවිධ ක්ෂුද්‍ර මිණුම් සලකුණු මත කාර්ය සාධනයේ 10 ගුණයකට වඩා වැඩි වීමක් පෙන්නුම් කළේය. අපගේ අදහස වූයේ Cython භාවිතයෙන් Python මොඩියුල C modules වෙත සම්පාදනය කිරීම සහ Type annotations Run-time type checks බවට පත් කිරීමයි (සාමාන්යයෙන් Type annotations ධාවන වේලාවේදී නොසලකා හරින අතර Type checking systems මගින් පමණක් භාවිතා කරනු ලැබේ). අපි ඇත්තටම Python වෙතින් mypy ක්රියාත්මක කිරීම ස්ථිතික ලෙස ටයිප් කිරීමට නිර්මාණය කර ඇති, එය හරියටම Python මෙන් පෙනෙන (සහ, බොහෝ දුරට, ක්‍රියා කරන) භාෂාවකට පරිවර්තනය කිරීමට සැලසුම් කළෙමු. (මෙවැනි හරස් භාෂා සංක්‍රමණය mypy ව්‍යාපෘතියේ සම්ප්‍රදායක් බවට පත්ව ඇත. මුල් mypy ක්රියාත්මක කිරීම Alore හි ලියා ඇත, පසුව Java සහ Python හි වාක්‍ය සංක්‍රමණ දෙමුහුන් විය).
CPython extension API වෙත අවධානය යොමු කිරීම ව්‍යාපෘති කළමනාකරණ හැකියාවන් අහිමි නොකිරීමට ප්‍රධාන විය. mypy හට අවශ්ය අතථ්‍ය යන්ත්‍රයක් හෝ පුස්තකාලයක් ක්රියාත්මක කිරීමට අපට අවශ්ය නොවීය. ඊට අමතරව, අපට තවමත් සම්පූර්ණ පයිතන් පරිසර පද්ධතියට සහ සියලුම මෙවලම් (පයිටෙස්ට් වැනි) වෙත ප්රවේශය ඇත. මෙයින් අදහස් කළේ සංවර්‍ධනයේදී අපට අර්ථකථනය කරන ලද පයිතන් කේතය දිගටම භාවිතා කළ හැකි බවත්, කේතය සම්පාදනය වන තෙක් බලා සිටීම වෙනුවට කේත වෙනස් කිරීම් සහ එය පරීක්ෂා කිරීමේ ඉතා වේගවත් රටාවක් සමඟ දිගටම වැඩ කිරීමට අපට ඉඩ සලසයි. අපි පුටු දෙකක ඉඳගෙන ලොකු වැඩක් කරනවා වගේ පෙනුණා, කියන්න, අපි එයට ආදරය කළා.
අපි mypyc ලෙස හැඳින්වූ සම්පාදකය (වර්ග විශ්ලේෂණය සඳහා mypy ඉදිරිපස අන්තයක් ලෙස භාවිතා කරන බැවින්) ඉතා සාර්ථක ව්‍යාපෘතියක් බවට පත් විය. සමස්තයක් වශයෙන්, අපි හැඹිලි නොමැතිව නිතර mypy ධාවනය සඳහා ආසන්න වශයෙන් 4x වේගයක් ලබා ගත්තෙමු. mypyc ව්‍යාපෘතියේ හරය සංවර්ධනය කිරීම සඳහා Michael Sullivan, Ivan Levkivsky, Hugh Hahn සහ මගේ කුඩා කණ්ඩායමකට දින දර්ශන මාස 4ක් පමණ ගත විය. මෙම කාර්යය ප්‍රමාණය mypy නැවත ලිවීමට අවශ්ය ප්‍රමාණයට වඩා ඉතා කුඩා විය, උදාහරණයක් ලෙස, C++ හෝ Go හි. ඒ වගේම අපිට ව්‍යාපෘතිය වෙනත් භාෂාවකින් නැවත ලිවීමේදී කරන්න තිබුනාට වඩා බොහොම අඩුවෙන් වෙනස්කම් කරන්න සිද්ධ වුනා. අනෙකුත් Dropbox ක්‍රමලේඛකයින්ට ඔවුන්ගේ කේතය සම්පාදනය කිරීමට සහ වේගවත් කිරීමට එය භාවිතා කළ හැකි මට්ටමකට mypyc ගෙන ඒමට අපට හැකි වනු ඇතැයි අපි බලාපොරොත්තු වෙමු.
මෙම මට්ටමේ කාර්ය සාධනය සාක්ෂාත් කර ගැනීම සඳහා, අපට සිත්ගන්නා ඉංජිනේරු විසඳුම් කිහිපයක් යෙදීමට සිදු විය. මේ අනුව, compiler හට වේගවත්, පහත් මට්ටමේ C ඉදිකිරීම් භාවිතා කිරීමෙන් බොහෝ මෙහෙයුම් වේගවත් කළ හැක.උදාහරණයක් ලෙස, සම්පාදනය කරන ලද ශ්‍රිත ඇමතුමක් C ශ්‍රිත ඇමතුමක් බවට පරිවර්තනය වේ. එවැනි ඇමතුමක් අර්ථකථන ශ්‍රිතයක් ඇමතීමට වඩා වේගවත් වේ. ශබ්ද කෝෂ සෙවීම් වැනි සමහර මෙහෙයුම් තවමත් CPython වෙතින් සාමාන්‍ය C-API ඇමතුම් භාවිතා කරමින් සම්බන්ධ වී ඇති අතර ඒවා සම්පාදනය කරන විට සුළු වශයෙන් වේගවත් විය. අර්ථ නිරූපණය මගින් නිර්මාණය කරන ලද පද්ධතියේ අමතර බර ඉවත් කිරීමට අපට හැකි විය, නමුත් මේ අවස්ථාවේ දී මෙය කාර්ය සාධනය අනුව කුඩා වාසියක් පමණක් ලබා දුන්නේය.
වඩාත් පොදු "මන්දගාමී" මෙහෙයුම් හඳුනා ගැනීම සඳහා, අපි කේත පැතිකඩ සිදු කළා. මෙම දත්ත වලින් සන්නද්ධව, අපි mypyc එවැනි මෙහෙයුම් සඳහා වේගවත් C කේතයක් ජනනය වන පරිදි වෙනස් කිරීමට උත්සාහ කළෙමු, නැතහොත් වේගවත් මෙහෙයුම් භාවිතයෙන් අනුරූප Python කේතය නැවත ලිවීමට උත්සාහ කළෙමු (සමහර විට අපට එම හෝ වෙනත් ගැටළුවක් සඳහා ප්‍රමාණවත් තරම් සරල විසඳුමක් නොතිබුණි) . සම්පාදකය ස්වයංක්‍රීයව එකම පරිවර්තනයක් සිදු කිරීමට වඩා පයිතන් කේතය නැවත ලිවීම ගැටලුවට පහසු විසඳුමක් විය. දිගු කාලීනව, අපට මෙම පරිවර්තන බොහොමයක් ස්වයංක්‍රීය කිරීමට අවශ්ය විය, නමුත් එම අවස්ථාවේ අපි අවම උත්සාහයකින් mypy වේගවත් කිරීමට අවධානය යොමු කළෙමු. තවද මෙම ඉලක්කය කරා ගමන් කිරීමේදී අපි කොන් කිහිපයක් කපා ගත්තෙමු.
ඉදිරියට පැවැත්වේ…
හිතවත් පා readers කයින්! mypy ව්‍යාපෘතියේ පැවැත්ම ගැන ඔබ දැනගත් විට එය පිළිබඳ ඔබේ හැඟීම් මොනවාද?
මූලාශ්රය: www.habr.com