Python ကုဒ် လိုင်းပေါင်း ၄ သန်းကို စာရိုက်စစ်ဆေးရန် လမ်းကြောင်း။ အပိုင်း 4

ယနေ့ကျွန်ုပ်တို့သည် Python ကုဒ်လိုင်းသန်းပေါင်းများစွာအတွက် Dropbox မှ အမျိုးအစားထိန်းချုပ်မှုပုံစံကို ဘာသာပြန်ခြင်း၏ ဒုတိယအပိုင်းကို ထုတ်ဝေလျက်ရှိသည်။

→ အပိုင်း ၁ ကိုဖတ်ပါ။

တရားဝင် အမျိုးအစား ပံ့ပိုးမှု (PEP 484)

Hack Week သည် 2014 ခုနှစ်အတွင်း Dropbox တွင် mypy နှင့်ကျွန်ုပ်တို့၏ပထမဆုံးပြင်းထန်သောစမ်းသပ်မှုများကိုပြုလုပ်ခဲ့ပါသည်။ Hack Week သည် Dropbox မှကျင်းပသောတစ်ပတ်ကြာပွဲဖြစ်သည်။ ဤကာလအတွင်း ဝန်ထမ်းများသည် မိမိတို့အလိုရှိသည့်အတိုင်း လုပ်ဆောင်နိုင်ပါသည်။ Dropbox ၏အကျော်ကြားဆုံးနည်းပညာပရောဂျက်အချို့သည် ဤကဲ့သို့သောဖြစ်ရပ်များတွင်စတင်ခဲ့သည်။ ဤစမ်းသပ်မှု၏ရလဒ်အနေဖြင့် mypy သည် ပရောဂျက်ကို ကျယ်ကျယ်ပြန့်ပြန့်အသုံးပြုရန်အဆင်သင့်မဖြစ်သေးသော်လည်း mypy သည် အလားအလာကောင်းသည်ဟု ကျွန်ုပ်တို့ကောက်ချက်ချခဲ့သည်။

ထိုအချိန်တွင်၊ Python အမျိုးအစား အရိပ်အမြွက်စနစ်များကို စံနမူနာပြုရန် စိတ်ကူးသည် လေထဲတွင် ရှိနေသည်။ ကျွန်တော်ပြောခဲ့သလိုပဲ၊ Python 3.0 မှာ လုပ်ဆောင်ချက်တွေအတွက် type annotations တွေကို သုံးနိုင်ပေမယ့် သတ်မှတ်ထားတဲ့ syntax နဲ့ semantics တွေမပါဘဲ မတရားသောအသုံးအနှုန်းတွေသာဖြစ်ပါတယ်။ ပရိုဂရမ်ကို လုပ်ဆောင်နေစဉ်အတွင်း၊ ဤမှတ်ချက်များကို အများစုမှာ ရိုးရိုးရှင်းရှင်း လျစ်လျူရှုခဲ့သည်။ Hack Week ပြီးနောက်၊ ကျွန်ုပ်တို့သည် စံနှုန်းသတ်မှတ်ခြင်းဆိုင်ရာ ဝေါဟာရများကို စတင်လုပ်ဆောင်ခဲ့သည်။ ဤလုပ်ငန်းသည် ပေါ်ပေါက်လာခဲ့သည်။ PEP ၃၄၃ (Guido van Rossum၊ Łukasz Langa နဲ့ ကျွန်တော် ဒီစာတမ်းအတွက် ပူးပေါင်းခဲ့ပါတယ်)။

ကျွန်ုပ်တို့၏ သဘောထားကို နှစ်ဖက်မြင်နိုင်သည်။ ပထမဦးစွာ၊ Python ဂေဟစနစ်တစ်ခုလုံးသည် အမျိုးအစားအရိပ်အမြွက်များကို အသုံးပြုခြင်းအတွက် ဘုံချဉ်းကပ်မှုတစ်ခု (Python တွင်အသုံးပြုသည့်အသုံးအနှုန်းတစ်ခု "type annotations" နှင့်ညီမျှသည်) ကိုအသုံးပြုရန် မျှော်လင့်ပါသည်။ ဖြစ်နိုင်ခြေရှိသော အန္တရာယ်များကိုပေး၍ ယင်းသည် နှစ်ဦးနှစ်ဖက် သဟဇာတမဖြစ်သော နည်းလမ်းများစွာကို အသုံးပြုခြင်းထက် ပိုကောင်းပါသည်။ ဒုတိယ၊ ကျွန်ုပ်တို့သည် Python အသိုက်အဝန်း၏ အဖွဲ့ဝင်များစွာနှင့် အမျိုးအစား မှတ်စာယန္တရားများကို ပွင့်ပွင့်လင်းလင်း ဆွေးနွေးလိုပါသည်။ Python ပရိုဂရမ်မာများ၏အမြင်တွင် ဘာသာစကား၏အခြေခံအယူအဆများမှ ကျွန်ုပ်တို့သည် “အယူဖောက်ပြန်သူများ” ကဲ့သို့မဖြစ်လိုသည့်အချက်ကြောင့် ဤဆန္ဒသည် တစ်စိတ်တစ်ပိုင်းအားဖြင့် ဆုံးဖြတ်ခဲ့ခြင်းဖြစ်သည်။ ၎င်းသည် "duck typing" ဟုလူသိများသော dynamically typed language တစ်ခုဖြစ်သည်။ ရပ်ရွာတွင်၊ အစပိုင်းတွင်၊ အငြိမ်စာရိုက်ခြင်းဆိုင်ရာ အတွေးအမြင်အပေါ် သံသယဖြစ်ဖွယ်သဘောထားသည် ပေါ်ပေါက်လာရန် မကူညီနိုင်ပေ။ သို့သော် static typing သည် မဖြစ်မနေ မလိုအပ်တော့ကြောင်း သိသာထင်ရှားလာပြီးနောက် ထိုစိတ်ဓာတ်များ လျော့ပါးသွားသည် (၎င်းသည် အမှန်တကယ် အသုံးဝင်ကြောင်း လူများ သိရှိလာပြီးနောက်)။

နောက်ဆုံးတွင် လက်ခံကျင့်သုံးခဲ့သော အရိပ်အမြွက်စာအထားအသိုအမျိုးအစားသည် ထိုအချိန်က mypy ပံ့ပိုးပေးသည့်အရာနှင့် အလွန်ဆင်တူသည်။ PEP 484 ကို 3.5 ခုနှစ်တွင် Python 2015 ဖြင့် ထုတ်ပြန်ခဲ့သည်။ Python သည် dynamically typed language မဟုတ်တော့ပါ။ ဒီဖြစ်ရပ်ကို Python သမိုင်းမှာ အရေးပါတဲ့ မှတ်တိုင်တစ်ခုအဖြစ် တွေးကြည့်ချင်ပါတယ်။

ရွှေ့ပြောင်းခြင်းစတင်ခြင်း။

2015 နှစ်ကုန်ပိုင်းတွင် Dropbox သည် mypy တွင်အလုပ်လုပ်ရန်လူ XNUMX ယောက်အဖွဲ့ကိုဖန်တီးခဲ့သည်။ ၎င်းတို့တွင် Guido van Rossum၊ Greg Price နှင့် David Fisher တို့ ပါဝင်သည်။ ထိုအချိန်မှစ၍ အခြေအနေသည် အလွန်လျင်မြန်စွာ တိုးတက်လာသည်။ mypy ကြီးထွားမှုအတွက် ပထမဆုံးအတားအဆီးမှာ စွမ်းဆောင်ရည်ဖြစ်သည်။ အထက်က အရိပ်အမြွက်ပြောခဲ့သလိုပဲ ပရောဂျက်ရဲ့ အစောပိုင်းကာလတွေမှာ mypy အကောင်အထည်ဖော်မှုကို C လို့ ဘာသာပြန်ဖို့ စဉ်းစားခဲ့ပေမယ့် အခုအချိန်မှာတော့ ဒီစိတ်ကူးဟာ စာရင်းထဲက လွတ်သွားပါပြီ။ mypy ကဲ့သို့သော ကိရိယာများအတွက် လုံလောက်မှု မမြန်ဆန်သော CPython စကားပြန်ကို အသုံးပြု၍ စနစ်ကို လုပ်ဆောင်ခြင်းတွင် ကျွန်ုပ်တို့ ရပ်တန့်နေပါသည်။ (JIT compiler ဖြင့် PyPy ပရောဂျက်သည် အခြား Python အကောင်အထည်ဖော်မှုကို အထောက်အကူမပြုပါ။)

ကံကောင်းစွာဖြင့်၊ အချို့သော အယ်လဂိုရီသမ်ဆိုင်ရာ တိုးတက်မှုများသည် ကျွန်ုပ်တို့၏အကူအညီကို ဤနေရာတွင် ရောက်ရှိလာပါသည်။ ပထမဆုံး အားကောင်းသော “အရှိန်မြှင့်စက်” သည် တိုးမြင့်စစ်ဆေးခြင်း၏ အကောင်အထည်ဖော်မှုဖြစ်သည်။ ဤတိုးတက်မှု၏နောက်ကွယ်က အယူအဆသည် ရိုးရှင်းသည်- အကယ်၍ mypy ၏ယခင်လည်ပတ်မှုနောက်ပိုင်း module ၏မှီခိုမှုအားလုံးသည် မပြောင်းလဲပါက၊ မှီခိုမှုနှင့်အတူလုပ်ဆောင်နေစဉ် ယခင် run စဉ်အတွင်း သိမ်းဆည်းထားသောဒေတာကို ကျွန်ုပ်တို့အသုံးပြုနိုင်ပါသည်။ ပြုပြင်ထားသောဖိုင်များနှင့် ၎င်းတို့အပေါ် မှီခိုနေသောဖိုင်များပေါ်တွင် အမျိုးအစားစစ်ဆေးခြင်းကို လုပ်ဆောင်ရန်သာ လိုအပ်ပါသည်။ Mypy သည် အနည်းငယ် ပိုသွားသည်- အကယ်၍ module တစ်ခု၏ ပြင်ပမျက်နှာပြင် မပြောင်းလဲပါက၊ ဤ module ကိုတင်သွင်းသော အခြား module များသည် ထပ်မံစစ်ဆေးရန် မလိုအပ်တော့ဟု mypy မှ ယူဆပါသည်။

ရှိပြီးသားကုဒ်အမြောက်အမြားကို မှတ်သားထားသည့်အခါ တိုးမြင့်စစ်ဆေးခြင်းက ကျွန်ုပ်တို့ကို များစွာအထောက်အကူဖြစ်စေပါသည်။ အဓိကအချက်မှာ ဤလုပ်ငန်းစဉ်တွင် မှတ်ချက်များကို ကုဒ်သို့ ဖြည်းဖြည်းချင်း ထည့်သွင်းပြီး တဖြည်းဖြည်း တိုးတက်ကောင်းမွန်လာသောကြောင့် ဤလုပ်ငန်းစဉ်တွင် mypy ၏ ထပ်ကာထပ်ကာ လုပ်ဆောင်မှုများ အများအပြား ပါဝင်နေပါသည်။ mypy ကို စစ်ဆေးရန် မှီခိုမှုများစွာရှိသောကြောင့် ပထမအကြိမ်ပြေးခြင်းမှာ အလွန်နှေးကွေးနေသေးသည်။ ထို့နောက် အခြေအနေတိုးတက်စေရန်၊ ကျွန်ုပ်တို့သည် ဝေးလံခေါင်သီသော သိမ်းဆည်းခြင်း ယန္တရားတစ်ခုကို အကောင်အထည်ဖော်ခဲ့သည်။ mypy သည် စက်တွင်းကက်ရှ်သည် ခေတ်မမီတော့ကြောင်း တွေ့ရှိပါက၊ ၎င်းသည် ဗဟိုချုပ်ကိုင်ထားသော သိုလှောင်မှုမှ codebase တစ်ခုလုံးအတွက် လက်ရှိ cache snapshot ကို ဒေါင်းလုဒ်လုပ်ပါသည်။ ထို့နောက် ၎င်းသည် ဤလျှပ်တစ်ပြက်ရိုက်ချက်အား အသုံးပြု၍ တိုးမြင့်စစ်ဆေးမှုကို လုပ်ဆောင်သည်။ ၎င်းသည် mypy ၏စွမ်းဆောင်ရည်ကိုမြှင့်တင်ရန်ကျွန်ုပ်တို့အားနောက်ထပ်ကြီးမားသောခြေလှမ်းတစ်လှမ်းကိုလှမ်းစေသည်။

၎င်းသည် Dropbox တွင် အမျိုးအစားစစ်ဆေးခြင်းကို လျင်မြန်ပြီး သဘာဝအတိုင်း လက်ခံကျင့်သုံးသည့် ကာလဖြစ်သည်။ 2016 နှစ်ကုန်တွင်၊ အမျိုးအစားမှတ်ချက်များပါရှိသော Python ကုဒ်စာကြောင်း 420000 ခန့်ရှိနှင့်ပြီးဖြစ်သည်။ အသုံးပြုသူအများအပြားသည် အမျိုးအစားစစ်ဆေးခြင်းကို စိတ်အားထက်သန်ကြသည်။ ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များသည် Dropbox mypy ကို ပိုမိုအသုံးပြုလာကြသည်။

အဲဒီတုန်းက အရာအားလုံးက ကောင်းနေပေမယ့် ကျွန်တော်တို့ လုပ်စရာတွေ အများကြီး ကျန်ပါသေးတယ်။ ကျွန်ုပ်တို့သည် ပရောဂျက်၏ ပြဿနာဧရိယာများကို ခွဲခြားသတ်မှတ်ရန်နှင့် မည်သည့်ပြဿနာများကို ဦးစွာဖြေရှင်းရန် လိုအပ်သည်ကို နားလည်ရန်အတွက် အချိန်အခါအလိုက် အတွင်းပိုင်းအသုံးပြုသူစစ်တမ်းများကို စတင်ဆောင်ရွက်ခဲ့ပါသည်။ သိသာထင်ရှားလာသောအခါတွင် အရေးကြီးဆုံးမှာ အလုပ်နှစ်ခုဖြစ်သည်။ ပထမ၊ ကျွန်ုပ်တို့သည် ကုဒ်၏ အမျိုးအစားလွှမ်းခြုံမှုကို ပိုမိုလိုအပ်သည်၊ ဒုတိယ၊ ကျွန်ုပ်တို့သည် ပိုမိုမြန်ဆန်စွာ လုပ်ဆောင်ရန် mypy လိုအပ်ပါသည်။ mypy ကို အရှိန်မြှင့်ပြီး ကုမ္ပဏီပရောဂျက်များတွင် အကောင်အထည် ဖော်ရန် ကျွန်ုပ်တို့၏ လုပ်ငန်းသည် ပြီးပြည့်စုံရန် မဝေးသေးကြောင်း ရှင်းရှင်းလင်းလင်း သိရပါသည်။ ဤတာဝန်နှစ်ခု၏ အရေးပါမှုကို ကျွန်ုပ်တို့ အပြည့်အဝ သိရှိနားလည်ပြီး ၎င်းတို့အား ဖြေရှင်းရန် သတ်မှတ်ပေးထားပါသည်။

ပိုကုန်ထုတ်စွမ်းအား။

တိုးမြှင့်စစ်ဆေးမှုများသည် mypy ကိုပိုမိုမြန်ဆန်စေသော်လည်း ကိရိယာသည် လုံလောက်စွာမမြန်ဆန်သေးပါ။ တိုးမြှင့်စစ်ဆေးမှုများစွာသည် တစ်မိနစ်ခန့်ကြာသည်။ ဒီလိုဖြစ်ရတဲ့ အကြောင်းရင်းကတော့ စက်ဘီးစီး တင်သွင်းမှုပါပဲ။ ၎င်းသည် Python တွင်ရေးထားသော ကုဒ်ဘေ့စ်ကြီးများဖြင့် အလုပ်လုပ်ဖူးသူတိုင်းကို အံ့အားသင့်စေမည်မဟုတ်ပါ။ ကျွန်ုပ်တို့တွင် ရာနှင့်ချီသော module အစုံရှိပါသည်၊ တစ်ခုစီသည် အခြားအရာအားလုံးကို သွယ်ဝိုက်တင်သွင်းသည်။ သွင်းကုန်ကွင်းတစ်ခုရှိ ဖိုင်တစ်ခုခုကို ပြောင်းလဲခဲ့ပါက mypy သည် ထိုကွင်းဆက်ရှိ ဖိုင်အားလုံးကို လုပ်ဆောင်ရမည်ဖြစ်ပြီး ထိုကွင်းဆက်မှ မော်ဂျူးများကို မကြာခဏ တင်သွင်းသည့် မည်သည့် module မဆို လုပ်ဆောင်ရပါမည်။ ထိုကဲ့သို့သောသံသရာတစ်ခုမှာ Dropbox တွင်ပြဿနာများစွာဖြစ်စေသောနာမည်ကြီးသော "မှီခိုမှုအရှုပ်အထွေး" ဖြစ်သည်။ ဤဖွဲ့စည်းပုံတွင် module ရာပေါင်းများစွာပါ၀င်သည်နှင့်၊ ၎င်းကို တိုက်ရိုက် သို့မဟုတ် သွယ်ဝိုက်၍ စမ်းသပ်မှုများစွာကို တင်သွင်းစဉ်တွင်၊ ၎င်းကို ထုတ်လုပ်မှုကုဒ်တွင်လည်း အသုံးပြုခဲ့သည်။

မြို့ပတ်ရထား မှီခိုမှုများ၏ ဖြစ်နိုင်ခြေကို ကျွန်ုပ်တို့ သုံးသပ်ခဲ့သော်လည်း ၎င်းကို လုပ်ဆောင်ရန် အရင်းအမြစ်များ မရှိခဲ့ပါ။ ကျွန်ုပ်တို့ မသိသော ကုဒ်များ အလွန်များပါသည်။ ရလဒ်အနေဖြင့် ကျွန်ုပ်တို့သည် အခြားရွေးချယ်စရာချဉ်းကပ်မှုတစ်ခု ပေါ်ပေါက်လာခဲ့သည်။ "မှီခိုမှုရှုပ်ထွေးမှုများ" တွင်ပင် mypy အလုပ်ကိုအမြန်လုပ်ရန်ကျွန်ုပ်တို့ဆုံးဖြတ်ခဲ့သည်။ mypy daemon ကို အသုံးပြု၍ ဤပန်းတိုင်ကို အောင်မြင်ခဲ့သည်။ daemon သည် စိတ်ဝင်စားစရာကောင်းသော အင်္ဂါရပ်နှစ်ခုကို အကောင်အထည်ဖော်သည့် ဆာဗာလုပ်ငန်းစဉ်တစ်ခုဖြစ်သည်။ ပထမဦးစွာ၊ ၎င်းသည် memory တွင် codebase တစ်ခုလုံးနှင့်ပတ်သက်သောအချက်အလက်များကိုသိမ်းဆည်းထားသည်။ ဆိုလိုသည်မှာ သင် mypy ကိုဖွင့်တိုင်း၊ တင်သွင်းထားသော မှီခိုမှုထောင်ပေါင်းများစွာနှင့် သက်ဆိုင်သည့် ကက်ရှ်ဒေတာကို သင်တင်ရန် မလိုအပ်ပါ။ ဒုတိယအနေနှင့်၊ အသေးစားဖွဲ့စည်းပုံယူနစ်အဆင့်တွင်၊ လုပ်ဆောင်ချက်များနှင့် အခြားအရာများကြားတွင် မှီခိုမှုကို ဂရုတစိုက် ပိုင်းခြားစိတ်ဖြာသည်။ ဥပမာပေးရရင် function ပေါ့။ foo function ကိုခေါ်သည်။ barပြီးတော့ မှီခိုမှုတစ်ခုရှိတယ်။ foo от bar. ဖိုင်တစ်ခုပြောင်းသောအခါ၊ daemon သည် ဦးစွာ သီးခြားခွဲထားခြင်းဖြင့် ပြောင်းလဲထားသောဖိုင်ကိုသာ လုပ်ဆောင်သည်။ ထို့နောက် ၎င်းသည် ပြောင်းလဲထားသော လုပ်ဆောင်ချက် လက်မှတ်များကဲ့သို့သော အဆိုပါဖိုင်၏ ပြင်ပမြင်နိုင်သော အပြောင်းအလဲများကို ကြည့်ရှုသည်။ daemon သည် တင်သွင်းမှုများနှင့်ပတ်သက်သော အသေးစိတ်အချက်အလက်များကို အသုံးပြု၍ ပြုပြင်ထားသောလုပ်ဆောင်ချက်ကို အမှန်တကယ်အသုံးပြုသည့် အဆိုပါလုပ်ဆောင်ချက်များကို နှစ်ဆစစ်ဆေးရန်သာ အသုံးပြုသည်။ ပုံမှန်အားဖြင့်၊ ဤချဉ်းကပ်မှုဖြင့် သင်သည် အလွန်နည်းပါးသော လုပ်ဆောင်ချက်များကို စစ်ဆေးရန် လိုအပ်သည်။

မူရင်း mypy အကောင်အထည်ဖော်မှုသည် တစ်ကြိမ်လျှင် ဖိုင်တစ်ခုလုပ်ဆောင်ခြင်းအပေါ် အလေးအနက်ထားသောကြောင့် ဤအရာအားလုံးကို အကောင်အထည်ဖော်ရန် မလွယ်ကူပါ။ ကုဒ်တွင် တစ်စုံတစ်ရာ ပြောင်းလဲသွားသည့် ကိစ္စများတွင် ထပ်ခါတလဲလဲ စစ်ဆေးမှုများ လိုအပ်သည့် နယ်နိမိတ်မျဉ်း အခြေအနေများစွာကို ကျွန်ုပ်တို့ ကိုင်တွယ်ဖြေရှင်းခဲ့ရသည်။ ဥပမာအားဖြင့်၊ class တစ်ခုကို base class အသစ်တစ်ခု သတ်မှတ်ပေးသောအခါ ၎င်းသည် ဖြစ်ပေါ်လာသည်။ ကျွန်ုပ်တို့ အလိုရှိသည်ကို လုပ်ဆောင်ပြီးသည်နှင့်၊ ကျွန်ုပ်တို့သည် တိုးမြှင့်စစ်ဆေးမှုအများစု၏ လုပ်ဆောင်ချိန်ကို စက္ကန့်အနည်းငယ်သာ လျှော့ချနိုင်ခဲ့သည်။ ဒါဟာ ကျွန်တော်တို့အတွက် ကြီးမားတဲ့ အောင်ပွဲတစ်ခုလိုပါပဲ။

ပိုလို့တောင် ကုန်ထုတ်စွမ်းအား !

အထက်တွင် ဆွေးနွေးခဲ့သော အဝေးထိန်း ကက်ရှာခြင်းနှင့်အတူ၊ mypy daemon သည် ပရိုဂရမ်မာတစ်ဦး မကြာခဏ အမျိုးအစားစစ်ဆေးခြင်းကို လုပ်ဆောင်ပြီး ဖိုင်အနည်းအများသို့ ပြောင်းလဲမှုများ ပြုလုပ်သည့်အခါ ဖြစ်ပေါ်လာသည့် ပြဿနာများကို လုံးလုံးနီးပါး ဖြေရှင်းပေးခဲ့သည်။ သို့သော်၊ အခွင့်သာသောအသုံးပြုမှုအနည်းဆုံးကိစ္စတွင် စနစ်စွမ်းဆောင်ရည်သည် အကောင်းဆုံးနှင့် အလှမ်းဝေးနေသေးသည်။ mypy ၏ သန့်ရှင်းသော စတင်မှုတစ်ခုသည် 15 မိနစ်ကျော် ကြာနိုင်သည်။ ပြီးတော့ ဒါက ကျွန်တော်တို့ ကျေနပ်ခဲ့တာထက် အများကြီး ပိုပါတယ်။ ပရိုဂရမ်မာများသည် ကုဒ်အသစ်များကို ဆက်လက်ရေးသားပြီး ရှိပြီးသားကုဒ်တွင် မှတ်ချက်များကို ထည့်ခြင်းဖြင့် အပတ်တိုင်း အခြေအနေ ပိုဆိုးလာသည်။ ကျွန်ုပ်တို့၏အသုံးပြုသူများသည် စွမ်းဆောင်ရည်ပိုမိုရရှိရန် ဆာလောင်နေသေးသော်လည်း လမ်းတစ်ဝက်တွင် ၎င်းတို့နှင့်တွေ့ဆုံရသည့်အတွက် ဝမ်းသာပါသည်။

mypy နှင့် ပတ်သက်၍ အစောပိုင်း စိတ်ကူးများထဲမှ တစ်ခုကို ပြန်သွားရန် ဆုံးဖြတ်ခဲ့သည်။ ပြောရရင် Python ကုဒ်ကို C ကုဒ်အဖြစ်ပြောင်းဖို့။ Cython ကိုစမ်းသပ်ခြင်း (သင် Python တွင်ရေးထားသောကုဒ်ကို C ကုဒ်သို့ဘာသာပြန်ရန်ခွင့်ပြုသည့်စနစ်) သည်ကျွန်ုပ်တို့အားမြင်သာသောမြန်နှုန်းကိုမပေးသောကြောင့်ကျွန်ုပ်တို့၏ကိုယ်ပိုင် compiler ရေးရန်စိတ်ကူးကိုပြန်လည်အသက်သွင်းရန်ဆုံးဖြတ်ခဲ့သည်။ mypy codebase (Python တွင်ရေးထားသော) တွင် လိုအပ်သော မှတ်ချက်အမျိုးအစားအားလုံးပါရှိပြီးဖြစ်သောကြောင့်၊ စနစ်အရှိန်မြှင့်ရန် ဤမှတ်ချက်များကိုအသုံးပြုရန် ကြိုးစားခြင်းသည် အကျိုးရှိမည်ဟု ကျွန်ုပ်တို့ထင်မြင်ပါသည်။ ဤအကြံဥာဏ်ကို စမ်းသပ်ရန် ရှေ့ပြေးပုံစံကို အမြန်ဖန်တီးခဲ့သည်။ ၎င်းသည် မိုက်ခရိုစံနှုန်းအမျိုးမျိုးတွင် စွမ်းဆောင်ရည် ၁၀ ဆကျော် တိုးလာမှုကို ပြသခဲ့သည်။ ကျွန်ုပ်တို့၏စိတ်ကူးမှာ Cython ကိုအသုံးပြု၍ Python modules များကို C module များသို့စုစည်းရန်နှင့် အမျိုးအစားမှတ်ချက်များကို run-time type checks အဖြစ်ပြောင်းလဲရန် (များသောအားဖြင့် type annotations များကို run-time တွင်လျစ်လျူရှုထားပြီး type checking systems မှသာအသုံးပြုသည်)။ ကျွန်ုပ်တို့သည် Python မှ mypy အကောင်အထည်ဖော်မှုကို ကိန်းသေစာရိုက်ရန် ဒီဇိုင်းထုတ်ထားသည့် ဘာသာစကားတစ်ခုသို့ ဘာသာပြန်ရန် အမှန်တကယ်စီစဉ်ထားပြီး၊ Python ကဲ့သို့ (အများစုမှာ၊ အလုပ်ဖြစ်သည်)။ (ဤဘာသာစကား ရွှေ့ပြောင်းခြင်းမျိုးသည် mypy ပရောဂျက်၏ အစဉ်အလာတစ်ခု ဖြစ်လာခဲ့သည်။ မူရင်း mypy အကောင်အထည်ဖော်မှုကို Alore ဖြင့် ရေးသားခဲ့ပြီး၊ ထို့နောက်တွင် Java နှင့် Python တို့၏ ပေါင်းစပ်ပေါင်းစပ်မှုတစ်ခု ရှိခဲ့သည်)။

CPython တိုးချဲ့မှု API ကို အာရုံစိုက်ခြင်းသည် ပရောဂျက်စီမံခန့်ခွဲမှုစွမ်းရည်များ မဆုံးရှုံးစေရန် သော့ချက်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် mypy လိုအပ်သော virtual machine သို့မဟုတ် မည်သည့်စာကြည့်တိုက်ကိုမဆို အကောင်အထည်ဖော်ရန် မလိုအပ်ပါ။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် Python ဂေဟစနစ်တစ်ခုလုံးနှင့် ကိရိယာများ (ဥပမာ pytest ကဲ့သို့သော) ကို အသုံးပြုခွင့်ရှိသေးသည်။ ဆိုလိုသည်မှာ ဖွံ့ဖြိုးတိုးတက်မှုကာလအတွင်း အဓိပ္ပာယ်ဖွင့်ဆိုထားသော Python ကုဒ်ကို ကျွန်ုပ်တို့ ဆက်လက်အသုံးပြုနိုင်မည်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် ကုဒ်များကို ပြုစုရန်စောင့်ဆိုင်းရမည့်အစား ၎င်းကို ကုဒ်အပြောင်းအလဲပြုလုပ်ခြင်းနှင့် စမ်းသပ်ခြင်း၏ အလွန်လျင်မြန်သောပုံစံဖြင့် ဆက်လက်လုပ်ဆောင်နိုင်စေမည်ဖြစ်သည်။ ကုလားထိုင်နှစ်လုံးပေါ်ထိုင်ပြီး စကားပြောရတာ ကောင်းတဲ့အလုပ်ကို လုပ်နေသလိုပဲ၊ ငါတို့က သဘောကျတယ်။

mypyc ဟုခေါ်သော compiler (၎င်းသည် mypy ကို အမျိုးအစားများကို ခွဲခြမ်းစိတ်ဖြာရန်အတွက် ရှေ့ဆုံးတွင် အသုံးပြုထားသောကြောင့်) အလွန်အောင်မြင်သော ပရောဂျက်တစ်ခု ဖြစ်လာခဲ့သည်။ ယေဘုယျအားဖြင့်၊ ကျွန်ုပ်တို့သည် ကက်ရှ်မပါဘဲ မကြာခဏ mypy လည်ပတ်မှုအတွက် ခန့်မှန်းခြေ 4 ဆ အရှိန်မြှင့်နိုင်ခဲ့သည်။ mypyc ပရောဂျက်၏ အဓိကအချက်ကို ဖော်ဆောင်ရာတွင် Michael Sullivan၊ Ivan Levkivsky၊ Hugh Hahn နှင့် ကျွန်ုပ်သည် ပြက္ခဒိန် ၄ လခန့်ရှိသော အဖွဲ့ငယ်တစ်ဖွဲ့ကို ယူဆောင်ခဲ့သည်။ ဤအလုပ်ပမာဏသည် mypy ကိုပြန်လည်ရေးသားရန် လိုအပ်သည့်အရာထက် များစွာသေးငယ်သည် ဥပမာ၊ C++ သို့မဟုတ် Go တွင်ဖြစ်သည်။ ပြီးတော့ ပရောဂျက်ကို တခြားဘာသာစကားနဲ့ ပြန်ရေးတဲ့အခါ လုပ်ရမယ့်အရာထက် ပရောဂျက်ကို အပြောင်းအလဲတွေ အများကြီးလုပ်ရတယ်။ အခြား Dropbox ပရိုဂရမ်မာများသည် ၎င်းတို့၏ကုဒ်ကို စုစည်းပြီး အရှိန်မြှင့်ရန် ၎င်းကို အသုံးပြုနိုင်သည့် mypyc အဆင့်သို့ ဆောင်ကြဉ်းပေးနိုင်မည်ဟုလည်း ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။

ဤအဆင့်ကိုရရှိရန် ကျွန်ုပ်တို့သည် စိတ်ဝင်စားစရာကောင်းသော အင်ဂျင်နီယာဆိုင်ရာ ဖြေရှင်းချက်အချို့ကို အသုံးပြုခဲ့ရပါသည်။ ထို့ကြောင့်၊ compiler သည် မြန်ဆန်ပြီး အဆင့်နိမ့် C တည်ဆောက်မှုများကို အသုံးပြုခြင်းဖြင့် လုပ်ဆောင်ချက်များစွာကို အရှိန်မြှင့်ပေးနိုင်သည်။ ဥပမာအားဖြင့် compiled function call ကို C function call သို့ ဘာသာပြန်ဆိုသည်။ ထိုသို့သောခေါ်ဆိုမှုသည် အဓိပ္ပာယ်ဖွင့်ဆိုထားသော လုပ်ဆောင်ချက်ကိုခေါ်ဆိုခြင်းထက် များစွာမြန်ဆန်ပါသည်။ အဘိဓာန်ရှာဖွေခြင်းကဲ့သို့သော အချို့သောလုပ်ဆောင်ချက်များသည် CPython မှ ပုံမှန် C-API ခေါ်ဆိုမှုများကို အသုံးပြုနေဆဲဖြစ်ပြီး၊ စုစည်းသည့်အခါ အနည်းငယ်ပိုမြန်ပါသည်။ ကျွန်ုပ်တို့သည် အဓိပ္ပါယ်ဖွင့်ဆိုချက်ဖြင့် ဖန်တီးထားသော စနစ်အပေါ် ထပ်လောင်းဝန်ပိုကို ဖယ်ရှားနိုင်ခဲ့သော်လည်း ဤကိစ္စတွင် စွမ်းဆောင်ရည်အရ အနည်းငယ်မျှသာ ရရှိခဲ့သည်။

အသုံးအများဆုံး "နှေးကွေးသော" လုပ်ဆောင်ချက်များကို ခွဲခြားသတ်မှတ်ရန်၊ ကျွန်ုပ်တို့သည် ကုဒ်ပရိုဖိုင်ကို လုပ်ဆောင်ခဲ့ပါသည်။ ဤဒေတာဖြင့် လက်နက်ကိုင်ဆောင်ထားသော mypyc ကို အရှိန်မြှင့်ရန် ကြိုးပမ်းခဲ့သည်၊ သို့မှသာ ၎င်းသည် လုပ်ဆောင်ချက်များအတွက် C ကုဒ်ကို ပိုမိုမြန်ဆန်စွာ ထုတ်လုပ်နိုင်စေရန်၊ သို့မဟုတ် ပိုမိုမြန်ဆန်သော လုပ်ဆောင်ချက်များကို အသုံးပြု၍ သက်ဆိုင်ရာ Python ကုဒ်ကို ပြန်လည်ရေးပါ (တခါတရံတွင် ထိုသို့မဟုတ် အခြားပြဿနာအတွက် ရိုးရှင်းလုံလောက်သော အဖြေမရှိပါ) . Python ကုဒ်ကို ပြန်လည်ရေးသားခြင်းသည် compiler သည် တူညီသောအသွင်ပြောင်းမှုကို အလိုအလျောက်လုပ်ဆောင်ခြင်းထက် ပြဿနာအတွက် ပိုမိုလွယ်ကူသော အဖြေတစ်ခုဖြစ်သည်။ ရေရှည်တွင်၊ ကျွန်ုပ်တို့သည် ဤပြောင်းလဲမှုများစွာကို အလိုအလျောက်လုပ်ဆောင်လိုသော်လည်း ထိုအချိန်တွင် ကျွန်ုပ်တို့သည် အနည်းငယ်မျှသောအားစိုက်ထုတ်မှုဖြင့် mypy ကိုအရှိန်မြှင့်ရန် အာရုံစိုက်ခဲ့ပါသည်။ ပြီးတော့ ဒီပန်းတိုင်ကို လျှောက်လှမ်းရာမှာ ထောင့်ပေါင်းများစွာ ဖြတ်ခဲ့ကြတယ်။

ဆက်ရန်…

ချစ်ခင်ရပါသောစာဖတ်သူများ! mypy ပရောဂျက်၏ တည်ရှိမှုကို သင်သိရှိသောအခါ သင်မည်သို့ထင်မြင်ယူဆခဲ့သနည်း။

source: www.habr.com