പൈത്തൺ കോഡിന്റെ 4 ദശലക്ഷം ലൈനുകൾ ടൈപ്പ് ചെക്ക് ചെയ്യുന്നതിനുള്ള പാത. ഭാഗം 1

പൈത്തൺ കോഡ് തരം നിയന്ത്രണവുമായി ഡ്രോപ്പ്ബോക്സ് എങ്ങനെ ഇടപെടുന്നു എന്നതിനെക്കുറിച്ചുള്ള മെറ്റീരിയലിന്റെ വിവർത്തനത്തിന്റെ ആദ്യ ഭാഗം ഞങ്ങൾ ഇന്ന് നിങ്ങളുടെ ശ്രദ്ധയിൽപ്പെടുത്തുന്നു.

ഡ്രോപ്പ്ബോക്സ് പൈത്തണിൽ ധാരാളം എഴുതുന്നു. ബാക്കെൻഡ് സേവനങ്ങൾക്കും ഡെസ്‌ക്‌ടോപ്പ് ക്ലയന്റ് ആപ്ലിക്കേഷനുകൾക്കുമായി ഞങ്ങൾ വളരെ വ്യാപകമായി ഉപയോഗിക്കുന്ന ഒരു ഭാഷയാണിത്. Go, TypeScript, Rust എന്നിവയും ഞങ്ങൾ ധാരാളം ഉപയോഗിക്കാറുണ്ട്, പക്ഷേ പൈത്തൺ ആണ് ഞങ്ങളുടെ പ്രധാന ഭാഷ. ഞങ്ങളുടെ സ്കെയിൽ കണക്കിലെടുക്കുമ്പോൾ, ഞങ്ങൾ ദശലക്ഷക്കണക്കിന് പൈത്തൺ കോഡുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, അത്തരം കോഡിന്റെ ഡൈനാമിക് ടൈപ്പിംഗ് അതിന്റെ ധാരണയെ അനാവശ്യമായി സങ്കീർണ്ണമാക്കുകയും തൊഴിൽ ഉൽപാദനക്ഷമതയെ സാരമായി ബാധിക്കുകയും ചെയ്തു. ഈ പ്രശ്‌നം ലഘൂകരിക്കുന്നതിന്, mypy ഉപയോഗിച്ച് ഞങ്ങളുടെ കോഡ് സ്റ്റാറ്റിക് ടൈപ്പ് ചെക്കിംഗിലേക്ക് ക്രമേണ പരിവർത്തനം ചെയ്യാൻ ഞങ്ങൾ തുടങ്ങി. പൈത്തണിനായുള്ള ഏറ്റവും ജനപ്രിയമായ ഒറ്റപ്പെട്ട തരം പരിശോധനാ സംവിധാനമാണിത്. Mypy ഒരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റാണ്, അതിന്റെ പ്രധാന ഡെവലപ്പർമാർ ഡ്രോപ്പ്ബോക്സിൽ പ്രവർത്തിക്കുന്നു.

ഈ സ്കെയിലിൽ പൈത്തൺ കോഡിൽ സ്റ്റാറ്റിക് ടൈപ്പ് ചെക്കിംഗ് നടപ്പിലാക്കിയ ആദ്യത്തെ കമ്പനികളിൽ ഒന്നാണ് ഡ്രോപ്പ്ബോക്സ്. ഈ ദിവസങ്ങളിൽ ആയിരക്കണക്കിന് പ്രോജക്ടുകളിൽ Mypy ഉപയോഗിക്കുന്നു. ഈ ഉപകരണം അവർ പറയുന്നതുപോലെ, എണ്ണമറ്റ തവണ "യുദ്ധത്തിൽ പരീക്ഷിച്ചു". ഇപ്പോൾ ഉള്ളിടത്ത് എത്താൻ ഒരുപാട് ദൂരം പോകേണ്ടി വന്നു. വിജയിക്കാത്ത പല ശ്രമങ്ങളും പരാജയപ്പെട്ട പരീക്ഷണങ്ങളും വഴിയിൽ ഉണ്ടായിട്ടുണ്ട്. ടൈപ്പ് ചെക്കുകളും ടൈപ്പ് സൂചനകളും എണ്ണമറ്റ പൈത്തൺ ഡെവലപ്പർമാർക്കിടയിൽ സർവസാധാരണമായിരിക്കുന്ന എന്റെ അക്കാദമിക് റിസർച്ച് പ്രോജക്റ്റിന്റെ ഭാഗമായി പൈത്തണിലെ സ്റ്റാറ്റിക് ടൈപ്പ് ചെക്കിംഗിന്റെ ചരിത്രം ഈ ഭാഗം വിവരിക്കുന്നു. ഈ സംവിധാനങ്ങളെ ഇപ്പോൾ IDE-കളും കോഡ് അനലൈസറുകളും പോലുള്ള വിവിധ ടൂളുകൾ പിന്തുണയ്ക്കുന്നു.

→ രണ്ടാം ഭാഗം വായിക്കുക

എന്തുകൊണ്ട് തരം പരിശോധന ആവശ്യമാണ്?

നിങ്ങൾ എപ്പോഴെങ്കിലും ചലനാത്മകമായി ടൈപ്പ് ചെയ്‌ത പൈത്തൺ ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ, എന്തുകൊണ്ടാണ് ഈയിടെയായി സ്റ്റാറ്റിക് ടൈപ്പിംഗിനെയും മൈപിയെയും കുറിച്ച് ഇത്രയധികം കോലാഹലങ്ങൾ ഉണ്ടായത് എന്നതിൽ നിങ്ങൾ അൽപ്പം ആശയക്കുഴപ്പത്തിലായേക്കാം. അല്ലെങ്കിൽ പൈത്തണിന്റെ ചലനാത്മകമായ ടൈപ്പിംഗ് കാരണം നിങ്ങൾക്ക് അത് ഇഷ്ടമായേക്കാം, സംഭവിക്കുന്നത് നിങ്ങളെ അസ്വസ്ഥനാക്കുന്നു. സ്റ്റാറ്റിക് ടൈപ്പിംഗിന്റെ മൂല്യത്തിന്റെ താക്കോൽ തീരുമാനങ്ങളുടെ സ്കെയിൽ ആണ്: നിങ്ങളുടെ പ്രോജക്റ്റ് വലുതാകുമ്പോൾ, നിങ്ങൾ സ്റ്റാറ്റിക് ടൈപ്പിംഗിലേക്ക് കൂടുതൽ ചായുന്നു, ആത്യന്തികമായി, നിങ്ങൾക്ക് അത് ശരിക്കും ആവശ്യമാണ്.

ഒരു പ്രോജക്റ്റ് വലുപ്പത്തിൽ പതിനായിരക്കണക്കിന് ലൈനുകളിൽ എത്തിയെന്ന് നമുക്ക് പറയാം, കൂടാതെ നിരവധി പ്രോഗ്രാമർമാർ അതിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഇത് മാറുന്നു. ഇതുപോലുള്ള ഒരു പ്രോജക്റ്റ് പരിഗണിക്കുമ്പോൾ, ഞങ്ങളുടെ അനുഭവത്തെ അടിസ്ഥാനമാക്കി, അതിന്റെ കോഡ് മനസ്സിലാക്കുന്നത് ഡെവലപ്പർ ഉൽപ്പാദനക്ഷമത നിലനിർത്തുന്നതിന് പ്രധാനമാണെന്ന് നമുക്ക് പറയാം. തരം വ്യാഖ്യാനങ്ങളില്ലാതെ, ഒരു ഫംഗ്‌ഷനിലേക്ക് എന്ത് ആർഗ്യുമെന്റുകൾ കൈമാറണം, അല്ലെങ്കിൽ ഒരു നിശ്ചിത ഫംഗ്‌ഷന് ഏത് തരം മൂല്യങ്ങൾ തിരികെ നൽകാമെന്നത് കണ്ടുപിടിക്കാൻ പ്രയാസമാണ്. ടൈപ്പ് വ്യാഖ്യാനങ്ങൾ ഉപയോഗിക്കാതെ ഉത്തരം നൽകാൻ ബുദ്ധിമുട്ടുള്ള സാധാരണ ചോദ്യങ്ങൾ ഇതാ:

• ഈ ഫംഗ്‌ഷൻ തിരികെ നൽകാമോ None?
• ഈ വാദം എന്തായിരിക്കണം? items?
• ആട്രിബ്യൂട്ട് തരം എന്താണ് id: int അതാണോ, str, അല്ലെങ്കിൽ ഏതെങ്കിലും ഇഷ്‌ടാനുസൃത തരം?
• ഈ വാദം ഒരു പട്ടികയായിരിക്കണമോ? അതിലേക്ക് ഒരു ട്യൂപ്പിൾ കടത്താൻ കഴിയുമോ?

ഇനിപ്പറയുന്ന തരത്തിലുള്ള വ്യാഖ്യാന കോഡ് സ്‌നിപ്പെറ്റ് നോക്കുകയും ഇതുപോലുള്ള ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാൻ ശ്രമിക്കുകയും ചെയ്താൽ, ഇതൊരു ലളിതമായ ജോലിയാണെന്ന് മാറുന്നു:

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

• read_metadata തിരികെ വരുന്നില്ല Noneകാരണം റിട്ടേൺ തരം അല്ല Optional[…].
• വാദം items വരികളുടെ ഒരു ക്രമമാണ്. ഇത് ഒരു ക്രമത്തിലും ആവർത്തിക്കാൻ കഴിയില്ല.
• ആട്രിബ്യൂട്ട് id ബൈറ്റുകളുടെ ഒരു സ്ട്രിംഗ് ആണ്.

ഒരു ആദർശ ലോകത്ത്, ബിൽറ്റ്-ഇൻ ഡോക്യുമെന്റേഷനിൽ (ഡോക്‌സ്ട്രിംഗ്) അത്തരം സൂക്ഷ്മതകളെല്ലാം വിവരിക്കുമെന്ന് ഒരാൾ പ്രതീക്ഷിക്കുന്നു. എന്നാൽ നിങ്ങൾ പ്രവർത്തിക്കേണ്ട കോഡിൽ അത്തരം ഡോക്യുമെന്റേഷൻ പലപ്പോഴും നിരീക്ഷിക്കപ്പെടുന്നില്ല എന്നതിന് അനുഭവം ധാരാളം ഉദാഹരണങ്ങൾ നൽകുന്നു. അത്തരം ഡോക്യുമെന്റേഷൻ കോഡിൽ ഉണ്ടെങ്കിലും, നിങ്ങൾക്ക് അതിന്റെ സമ്പൂർണ്ണ കൃത്യത കണക്കാക്കാൻ കഴിയില്ല. ഈ ഡോക്യുമെന്റേഷൻ വ്യക്തമല്ലാത്തതും കൃത്യമല്ലാത്തതും തെറ്റിദ്ധാരണയ്ക്ക് ഇടയുള്ളതുമായിരിക്കാം. വലിയ ടീമുകളിലോ വലിയ പ്രോജക്ടുകളിലോ, ഈ പ്രശ്നം വളരെ രൂക്ഷമാകും.

ആദ്യഘട്ടത്തിലോ മധ്യഘട്ടത്തിലോ ഉള്ള പ്രോജക്റ്റുകളിൽ പൈത്തൺ മികവ് പുലർത്തുന്നുണ്ടെങ്കിലും, ചില ഘട്ടങ്ങളിൽ വിജയകരമായ പ്രോജക്റ്റുകൾക്കും പൈത്തൺ ഉപയോഗിക്കുന്ന കമ്പനികൾക്കും ഒരു സുപ്രധാന ചോദ്യം നേരിടേണ്ടി വന്നേക്കാം: “ഞങ്ങൾ എല്ലാം സ്റ്റാറ്റിക്കലി ടൈപ്പ് ചെയ്‌ത ഭാഷയിൽ മാറ്റിയെഴുതണോ?”

mypy പോലുള്ള ടൈപ്പ് ചെക്കിംഗ് സിസ്റ്റങ്ങൾ ഡവലപ്പർക്ക് തരങ്ങൾ വിവരിക്കുന്നതിന് ഒരു ഔപചാരിക ഭാഷ നൽകിക്കൊണ്ട് മുകളിൽ പറഞ്ഞ പ്രശ്നം പരിഹരിക്കുന്നു, കൂടാതെ ആ തരം ഡിക്ലറേഷനുകൾ പ്രോഗ്രാം നടപ്പിലാക്കലുമായി പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് പരിശോധിച്ച് (ഓപ്ഷണലായി, അവയുടെ നിലനിൽപ്പ് പരിശോധിക്കുക). പൊതുവേ, ഈ സംവിധാനങ്ങൾ നമുക്ക് ശ്രദ്ധാപൂർവ്വം പരിശോധിച്ചുറപ്പിച്ച ഡോക്യുമെന്റേഷൻ പോലെയുള്ള എന്തെങ്കിലും നൽകുന്നുവെന്ന് നമുക്ക് പറയാം.

അത്തരം സംവിധാനങ്ങളുടെ ഉപയോഗത്തിന് മറ്റ് ഗുണങ്ങളുണ്ട്, അവ പൂർണ്ണമായും നിസ്സാരമല്ല:

• ടൈപ്പ് ചെക്കിംഗ് സിസ്റ്റത്തിന് ചില ചെറിയ (അത്ര ചെറുതല്ലാത്ത) പിശകുകൾ കണ്ടെത്താനാകും. ഒരു മൂല്യം പ്രോസസ്സ് ചെയ്യാൻ അവർ മറക്കുമ്പോൾ ഒരു സാധാരണ ഉദാഹരണം None അല്ലെങ്കിൽ മറ്റേതെങ്കിലും പ്രത്യേക അവസ്ഥ.
• റീഫാക്‌ടറിംഗ് കോഡ് വളരെ ലളിതമാക്കിയിരിക്കുന്നു, കാരണം ടൈപ്പ് ചെക്കർ എന്ത് കോഡ് മാറ്റണമെന്ന് കൃത്യമായി നിങ്ങളോട് പറയുന്നു. അതേ സമയം, ഞങ്ങൾ കോഡിന്റെ 100% ടെസ്റ്റ് കവറേജിൽ ആശ്രയിക്കേണ്ടതില്ല, അത് സാധാരണയായി ഏത് സാഹചര്യത്തിലും അസാധ്യമാണ്. എന്താണ് തെറ്റ് എന്ന് മനസിലാക്കാൻ സ്റ്റാക്ക് ട്രേസ് റിപ്പോർട്ടുകൾ ആഴത്തിൽ പരിശോധിക്കേണ്ടതില്ല.
• വലിയ പ്രൊജക്‌റ്റുകളിൽ പോലും, മൈപിയ്‌ക്ക് പലപ്പോഴും ഒരു സെക്കൻഡിന്റെ ഒരു അംശം കൊണ്ട് പൂർണ്ണമായ തരം പരിശോധന നടത്താൻ കഴിയും. കൂടാതെ റണ്ണിംഗ് ടെസ്റ്റുകൾ സാധാരണയായി പതിനായിരക്കണക്കിന് സെക്കൻഡുകളോ മിനിറ്റുകളോ എടുക്കും. ടൈപ്പ് ചെക്കിംഗ് സിസ്റ്റം പ്രോഗ്രാമർക്ക് തൽക്ഷണ ഫീഡ്‌ബാക്ക് നൽകുകയും അവന്റെ ജോലി വേഗത്തിൽ ചെയ്യാൻ അനുവദിക്കുകയും ചെയ്യുന്നു. വേഗത്തിലുള്ള കോഡ് ടെസ്റ്റ് ഫലങ്ങൾ ലഭിക്കുന്നതിന്, യഥാർത്ഥ എന്റിറ്റികളെ മോക്കുകളും പാച്ചുകളും ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്ന ദുർബലവും പരിപാലിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമായ യൂണിറ്റ് ടെസ്റ്റുകൾ അദ്ദേഹത്തിന് ഇനി എഴുതേണ്ടതില്ല.

PyCharm അല്ലെങ്കിൽ Visual Studio Code പോലുള്ള IDE-കളും എഡിറ്റർമാരും ഡവലപ്പർമാർക്ക് സ്വയമേവയുള്ള കോഡ് പൂർത്തീകരണം, പിശക് ഹൈലൈറ്റ് ചെയ്യൽ, സാധാരണയായി ഉപയോഗിക്കുന്ന ഭാഷാ നിർമ്മാണങ്ങൾക്കുള്ള പിന്തുണ എന്നിവ നൽകുന്നതിന് തരം വ്യാഖ്യാനങ്ങളുടെ ശക്തി ഉപയോഗിക്കുന്നു. ടൈപ്പിഫിക്കേഷൻ നൽകുന്ന ചില ഗുണങ്ങൾ ഇവയാണ്. ചില പ്രോഗ്രാമർമാർക്ക്, ഇതെല്ലാം ടൈപ്പിംഗിന് അനുകൂലമായ പ്രധാന വാദമാണ്. ഇത് നടപ്പിലാക്കിയ ഉടൻ തന്നെ നേട്ടങ്ങൾ കൊണ്ടുവരുന്ന ഒന്നാണ്. തരങ്ങൾക്കായുള്ള ഈ ഉപയോഗ കേസിന് mypy പോലുള്ള ഒരു പ്രത്യേക തരം പരിശോധന സംവിധാനം ആവശ്യമില്ല, എന്നിരുന്നാലും കോഡുമായി പൊരുത്തപ്പെടുന്ന തരത്തിലുള്ള വ്യാഖ്യാനങ്ങൾ നിലനിർത്താൻ mypy സഹായിക്കുന്നു എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

Mypy പശ്ചാത്തലം

ഞാൻ ഡ്രോപ്പ്ബോക്സിൽ ചേരുന്നതിന് കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് യുകെയിൽ, കേംബ്രിഡ്ജിൽ, മൈപി സ്റ്റോറി ആരംഭിച്ചു. എന്റെ ഡോക്ടറൽ ഗവേഷണത്തിന്റെ ഭാഗമായി, സ്റ്റാറ്റിക്കലി ടൈപ്പ് ചെയ്തതും ചലനാത്മകവുമായ ഭാഷകളെ ഏകീകരിക്കുന്ന വിഷയത്തിൽ ഞാൻ പ്രവർത്തിച്ചു. ജെറമി സീക്കിന്റെയും വാലിദ് താഹിന്റെയും ഇൻക്രിമെന്റൽ ടൈപ്പിംഗിനെക്കുറിച്ചുള്ള ഒരു ലേഖനവും ടൈപ്പ് ചെയ്ത റാക്കറ്റ് പ്രോജക്റ്റും എനിക്ക് പ്രചോദനമായി. വ്യത്യസ്ത പ്രോജക്റ്റുകൾക്കായി ഒരേ പ്രോഗ്രാമിംഗ് ഭാഷ ഉപയോഗിക്കുന്നതിനുള്ള വഴികൾ കണ്ടെത്താൻ ഞാൻ ശ്രമിച്ചു - ചെറിയ സ്ക്രിപ്റ്റുകൾ മുതൽ ദശലക്ഷക്കണക്കിന് വരികൾ അടങ്ങുന്ന കോഡ്ബേസുകൾ വരെ. അതേ സമയം, ഏതെങ്കിലും സ്കെയിലിലുള്ള ഒരു പ്രോജക്റ്റിൽ ഞാൻ വളരെയധികം വിട്ടുവീഴ്ചകൾ ചെയ്യേണ്ടതില്ലെന്ന് ഉറപ്പാക്കാൻ ഞാൻ ആഗ്രഹിച്ചു. ടൈപ്പ് ചെയ്യാത്ത ഒരു പ്രോട്ടോടൈപ്പ് പ്രോജക്റ്റിൽ നിന്ന് സമഗ്രമായി പരീക്ഷിച്ച, സ്ഥിരമായി ടൈപ്പ് ചെയ്‌ത പൂർത്തിയായ ഉൽപ്പന്നത്തിലേക്ക് ക്രമേണ മാറുക എന്ന ആശയമായിരുന്നു ഇതിന്റെയെല്ലാം ഒരു പ്രധാന ഭാഗം. ഈ ആശയങ്ങൾ ഈ ദിവസങ്ങളിൽ വലിയതോതിൽ പരിഗണിക്കപ്പെടുന്നു, എന്നാൽ 2010-ൽ ഇത് ഇപ്പോഴും സജീവമായി ഗവേഷണം നടക്കുന്ന ഒരു പ്രശ്നമായിരുന്നു.

ടൈപ്പ് ചെക്കിംഗിലെ എന്റെ പ്രാരംഭ പ്രവർത്തനം പൈത്തണിനെ ലക്ഷ്യം വച്ചുള്ളതായിരുന്നില്ല. പകരം ഞാൻ ഒരു ചെറിയ "വീട്ടിൽ നിർമ്മിച്ച" ഭാഷ ഉപയോഗിച്ചു അലോർ. ഞങ്ങൾ എന്തിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെന്ന് നിങ്ങൾക്ക് ഒരു ആശയം നൽകുന്നതിനുള്ള ഒരു ഉദാഹരണം ഇതാ (തരം വ്യാഖ്യാനങ്ങൾ ഓപ്ഷണലാണ്):

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

നിങ്ങളുടെ സ്വന്തം രൂപകൽപ്പനയുടെ ലളിതമായ ഭാഷ ഉപയോഗിക്കുന്നത് ശാസ്ത്രീയ ഗവേഷണത്തിൽ ഉപയോഗിക്കുന്ന ഒരു സാധാരണ സമീപനമാണ്. ഇത് അങ്ങനെയാണ്, കാരണം ഇത് വേഗത്തിൽ പരീക്ഷണങ്ങൾ നടത്തുന്നത് സാധ്യമാക്കുന്നു, കൂടാതെ ഗവേഷണത്തിന് പ്രസക്തമല്ലാത്തത് എളുപ്പത്തിൽ അവഗണിക്കാം എന്നതിനാലും. യഥാർത്ഥ ജീവിത പ്രോഗ്രാമിംഗ് ഭാഷകൾ സങ്കീർണ്ണമായ നിർവ്വഹണങ്ങളുള്ള വലിയ തോതിലുള്ള പ്രതിഭാസങ്ങളാണ്, ഇത് പരീക്ഷണങ്ങളെ മന്ദഗതിയിലാക്കുന്നു. എന്നിരുന്നാലും, ലളിതമായ ഭാഷയെ അടിസ്ഥാനമാക്കിയുള്ള ഏതൊരു ഫലവും സംശയാസ്പദമാണ്, കാരണം ഈ ഫലങ്ങൾ നേടുന്നതിൽ ഗവേഷകൻ ഭാഷകളുടെ പ്രായോഗിക ഉപയോഗത്തിന് പ്രധാനപ്പെട്ട പരിഗണനകൾ ത്യജിച്ചിരിക്കാം.

Alore-നുള്ള എന്റെ ടൈപ്പ് ചെക്കർ വളരെ പ്രതീക്ഷ നൽകുന്നതായി കാണപ്പെട്ടു, എന്നാൽ യഥാർത്ഥത്തിൽ Alore-ൽ എഴുതിയിട്ടില്ലാത്ത യഥാർത്ഥ കോഡ് ഉപയോഗിച്ച് ഇത് പരീക്ഷിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു. ഭാഗ്യവശാൽ, അലോർ ഭാഷ പ്രധാനമായും പൈത്തണിന്റെ അതേ ആശയങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതായിരുന്നു. പൈത്തൺ വാക്യഘടനയിലും സെമാന്റിക്‌സിലും പ്രവർത്തിക്കാൻ കഴിയുന്ന തരത്തിൽ ടൈപ്പ് ചെക്കർ പുനർരൂപകൽപ്പന ചെയ്യുന്നത് വളരെ എളുപ്പമായിരുന്നു. ഓപ്പൺ സോഴ്‌സ് പൈത്തൺ കോഡിൽ ടൈപ്പ് ചെക്കിംഗ് നടത്താൻ ഇത് ഞങ്ങളെ അനുവദിച്ചു. അലോർ കോഡ് പൈത്തൺ കോഡാക്കി മാറ്റാൻ ഞാൻ ഒരു ട്രാൻസ്‌പൈലറും എഴുതി, അത് എന്റെ ടൈപ്പ് ചെക്കർ കോഡ് വിവർത്തനം ചെയ്യാൻ ഉപയോഗിച്ചു. ഇപ്പോൾ എനിക്ക് പൈത്തണിൽ എഴുതിയ ഒരു ടൈപ്പ് ചെക്കിംഗ് സിസ്റ്റം ഉണ്ടായിരുന്നു, അത് പൈത്തണിന്റെ ഒരു ഉപവിഭാഗത്തെ പിന്തുണയ്ക്കുന്നു, ആ ഭാഷയുടെ ചില വ്യതിയാനങ്ങൾ! (അലോറിന് അർത്ഥമുള്ള ചില വാസ്തുവിദ്യാ തീരുമാനങ്ങൾ പൈത്തണിന് വളരെ അനുയോജ്യമല്ല; മൈപി കോഡ്ബേസിന്റെ ചില ഭാഗങ്ങളിൽ ഇത് ഇപ്പോഴും പ്രകടമാണ്.)

വാസ്തവത്തിൽ, എന്റെ ടൈപ്പ് സിസ്റ്റം പിന്തുണയ്ക്കുന്ന ഭാഷയെ ഇപ്പോൾ പൈത്തൺ എന്ന് വിളിക്കാൻ കഴിയില്ല: പൈത്തൺ 3-ന്റെ ടൈപ്പ് വ്യാഖ്യാന വാക്യഘടനയുടെ ചില പരിമിതികൾ കാരണം ഇത് പൈത്തണിന്റെ ഒരു വകഭേദമായിരുന്നു.

ഇത് ജാവയുടെയും പൈത്തണിന്റെയും മിശ്രിതം പോലെ കാണപ്പെട്ടു:

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

പൈത്തണിന്റെ ഈ ഫ്ലേവർ സിയിലേയ്ക്കോ ഒരുപക്ഷേ ജെവിഎം ബൈറ്റ്കോഡിലേക്കോ സമാഹരിച്ച് പ്രകടനം മെച്ചപ്പെടുത്താൻ ടൈപ്പ് വ്യാഖ്യാനങ്ങൾ ഉപയോഗിക്കുക എന്നതായിരുന്നു അക്കാലത്തെ എന്റെ ആശയങ്ങളിലൊന്ന്. ഞാൻ ഒരു പ്രോട്ടോടൈപ്പ് കംപൈലർ എഴുതുന്ന ഘട്ടത്തിലെത്തി, പക്ഷേ ടൈപ്പ് ചെക്കിംഗ് തന്നെ ഉപയോഗപ്രദമാണെന്ന് തോന്നിയതിനാൽ ഈ ആശയം ഉപേക്ഷിച്ചു.

സാന്താ ക്ലാരയിലെ PyCon 2013-ൽ ഞാൻ എന്റെ പ്രോജക്റ്റ് അവതരിപ്പിച്ചു. പൈത്തണിന്റെ ജീവകാരുണ്യ സ്വേച്ഛാധിപതിയായ ഗൈഡോ വാൻ റോസ്സുമായും ഞാൻ ഇതിനെക്കുറിച്ച് സംസാരിച്ചു. എന്റെ ഇഷ്‌ടാനുസൃത വാക്യഘടന ഒഴിവാക്കി സ്റ്റാൻഡേർഡ് പൈത്തൺ 3 വാക്യഘടനയിൽ ഉറച്ചുനിൽക്കാൻ അദ്ദേഹം എന്നെ ബോധ്യപ്പെടുത്തി. പൈത്തൺ 3 ഫംഗ്‌ഷൻ വ്യാഖ്യാനങ്ങളെ പിന്തുണയ്‌ക്കുന്നു, അതിനാൽ എന്റെ ഉദാഹരണം ചുവടെയുള്ള രീതിയിൽ വീണ്ടും എഴുതാം, അതിന്റെ ഫലമായി ഒരു സാധാരണ പൈത്തൺ പ്രോഗ്രാം ലഭിക്കും:

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

എനിക്ക് ചില വിട്ടുവീഴ്ചകൾ ചെയ്യേണ്ടി വന്നു (ആദ്യമായി, ഞാൻ എന്റെ സ്വന്തം വാക്യഘടന കണ്ടുപിടിച്ചത് അതിനാലാണ് എന്ന് സൂചിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു). പ്രത്യേകിച്ചും, അക്കാലത്തെ ഭാഷയുടെ ഏറ്റവും പുതിയ പതിപ്പായ പൈത്തൺ 3.3, വേരിയബിൾ വ്യാഖ്യാനങ്ങളെ പിന്തുണച്ചില്ല. അത്തരം വ്യാഖ്യാനങ്ങൾക്കുള്ള വിവിധ വാക്യഘടന ഓപ്ഷനുകൾ ഞാൻ ഗൈഡോയുമായി ഇമെയിൽ വഴി ചർച്ച ചെയ്തു. വേരിയബിളുകൾക്കായി ടൈപ്പ് കമന്റുകൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഇത് ലക്ഷ്യം നേടി, പക്ഷേ അൽപ്പം ബുദ്ധിമുട്ടുള്ളതായി കാണപ്പെട്ടു (പൈത്തൺ 3.6 ഞങ്ങൾക്ക് ഒരു നല്ല വാക്യഘടന നൽകി):

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

ടൈപ്പ് വ്യാഖ്യാനങ്ങൾക്കുള്ള ബിൽറ്റ്-ഇൻ പിന്തുണയില്ലാത്ത പൈത്തൺ 2-നെ പിന്തുണയ്ക്കുന്നതിനും ടൈപ്പ് കമന്റുകൾ ഉപയോഗപ്രദമാണ്:

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

ഈ (മറ്റ്) വിട്ടുവീഴ്ചകൾ യഥാർത്ഥത്തിൽ പ്രശ്നമല്ലെന്ന് മനസ്സിലായി - സ്റ്റാറ്റിക് ടൈപ്പിംഗിന്റെ പ്രയോജനങ്ങൾ അർത്ഥമാക്കുന്നത് ഉപയോക്താക്കൾ വളരെ കുറവുള്ള വാക്യഘടനയെക്കുറിച്ച് ഉടൻ മറന്നു എന്നാണ്. തരങ്ങളെ നിയന്ത്രിക്കുന്ന പൈത്തൺ കോഡ് പ്രത്യേക വാക്യഘടന ഉപയോഗിക്കാത്തതിനാൽ, നിലവിലുള്ള പൈത്തൺ ടൂളുകളും കോഡ് പ്രക്രിയകളും സാധാരണ നിലയിൽ തുടർന്നു, പുതിയ ടൂൾ പഠിക്കുന്നത് ഡവലപ്പർമാർക്ക് വളരെ എളുപ്പമാക്കി.

എന്റെ സീനിയർ തീസിസ് പൂർത്തിയാക്കിയ ശേഷം ഡ്രോപ്പ്ബോക്സിൽ ചേരാൻ ഗൈഡോ എന്നെ ബോധ്യപ്പെടുത്തി. മൈപിയുടെ ചരിത്രത്തിലെ ഏറ്റവും രസകരമായ കാര്യം ഇവിടെ തുടങ്ങുന്നു.

തുടരേണ്ടത് ...

പ്രിയ വായനക്കാർ! നിങ്ങൾ പൈത്തൺ ഉപയോഗിക്കുകയാണെങ്കിൽ, ഈ ഭാഷയിൽ നിങ്ങൾ വികസിപ്പിക്കുന്ന പ്രോജക്റ്റുകളുടെ സ്കെയിലിനെക്കുറിച്ച് ഞങ്ങളോട് പറയുക.

അവലംബം: www.habr.com