ເສັ້ນທາງໄປສູ່ການພິມລະຫັດ 4 ລ້ານແຖວຂອງລະຫັດ Python. ພາກທີ 1

ມື້ນີ້ພວກເຮົາເອົາມາໃຫ້ຄວາມສົນໃຈຂອງທ່ານສ່ວນທໍາອິດຂອງການແປຂອງເອກະສານກ່ຽວກັບວິທີການ Dropbox ຈັດການກັບການຄວບຄຸມປະເພດລະຫັດ Python.

Dropbox ຂຽນຫຼາຍໃນ Python. ມັນເປັນພາສາທີ່ພວກເຮົາໃຊ້ຢ່າງກວ້າງຂວາງທີ່ສຸດ, ທັງສໍາລັບການບໍລິການ back-end ແລະຄໍາຮ້ອງສະຫມັກລູກຄ້າ desktop. ພວກເຮົາຍັງໃຊ້ Go, TypeScript ແລະ Rust ຫຼາຍ, ແຕ່ Python ແມ່ນພາສາຕົ້ນຕໍຂອງພວກເຮົາ. ພິຈາລະນາຂະຫນາດຂອງພວກເຮົາ, ແລະພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບລະຫັດ Python ຫຼາຍລ້ານສາຍ, ມັນໄດ້ສະແດງໃຫ້ເຫັນວ່າການພິມແບບເຄື່ອນໄຫວຂອງລະຫັດດັ່ງກ່າວເຮັດໃຫ້ຄວາມເຂົ້າໃຈຂອງມັນສັບສົນໂດຍບໍ່ຈໍາເປັນແລະເລີ່ມສົ່ງຜົນກະທົບຕໍ່ການຜະລິດແຮງງານ. ເພື່ອຫຼຸດຜ່ອນບັນຫານີ້, ພວກເຮົາໄດ້ເລີ່ມຄ່ອຍໆປ່ຽນລະຫັດຂອງພວກເຮົາໄປສູ່ການກວດສອບປະເພດຄົງທີ່ໂດຍໃຊ້ mypy. ນີ້ອາດຈະເປັນລະບົບການກວດສອບປະເພດ standalone ທີ່ນິຍົມທີ່ສຸດສໍາລັບ Python. Mypy ແມ່ນໂຄງການແຫຼ່ງເປີດ, ຜູ້ພັດທະນາຕົ້ນຕໍຂອງມັນເຮັດວຽກຢູ່ໃນ Dropbox.

Dropbox ແມ່ນຫນຶ່ງໃນບໍລິສັດທໍາອິດທີ່ປະຕິບັດການກວດສອບປະເພດຄົງທີ່ໃນລະຫັດ Python ໃນລະດັບນີ້. Mypy ຖືກນໍາໃຊ້ໃນຫລາຍພັນໂຄງການໃນມື້ນີ້. ເຄື່ອງມືນີ້ນັບບໍ່ຖ້ວນ, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, "ຖືກທົດສອບໃນການສູ້ຮົບ." ພວກ​ເຮົາ​ໄດ້​ມາ​ເປັນ​ທາງ​ຍາວ​ເພື່ອ​ໄປ​ບ່ອນ​ທີ່​ພວກ​ເຮົາ​ຢູ່​ໃນ​ປັດ​ຈຸ​ບັນ​. ຄຽງຄູ່ກັນນັ້ນ, ໄດ້ມີການດຳເນີນງານທີ່ບໍ່ສຳເລັດ ແລະ ປະສົບຜົນສຳເລັດຫຼາຍຢ່າງ. ຂໍ້ຄວາມນີ້ກວມເອົາປະຫວັດຂອງການກວດສອບປະເພດຄົງທີ່ໃນ Python, ຕັ້ງແຕ່ເລີ່ມຕົ້ນທີ່ໂງ່ຈ້າເປັນສ່ວນຫນຶ່ງຂອງໂຄງການຄົ້ນຄ້ວາຂອງຂ້ອຍ, ຈົນເຖິງປັດຈຸບັນ, ເມື່ອການກວດສອບປະເພດແລະການຊີ້ບອກປະເພດໄດ້ກາຍເປັນເລື່ອງປົກກະຕິສໍາລັບນັກພັດທະນານັບບໍ່ຖ້ວນທີ່ຂຽນໃນ Python. ໃນປັດຈຸບັນກົນໄກເຫຼົ່ານີ້ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍເຄື່ອງມືຈໍານວນຫຼາຍເຊັ່ນ: IDEs ແລະການວິເຄາະລະຫັດ.

→ ອ່ານພາກທີສອງ

ເປັນຫຍັງການກວດສອບປະເພດຈຶ່ງຈໍາເປັນ?

ຖ້າທ່ານເຄີຍໃຊ້ Python ທີ່ພິມແບບໄດນາມິກ, ທ່ານອາດຈະມີຄວາມສັບສົນບາງຢ່າງວ່າເປັນຫຍັງມັນຈຶ່ງມີຄວາມວຸ້ນວາຍກ່ຽວກັບການພິມແບບຄົງທີ່ແລະ mypy ບໍ່ດົນມານີ້. ຫຼືບາງທີເຈົ້າມັກ Python ຊັດເຈນຍ້ອນການພິມແບບເຄື່ອນໄຫວຂອງມັນ, ແລະສິ່ງທີ່ເກີດຂຶ້ນພຽງແຕ່ເຮັດໃຫ້ເຈົ້າເສຍໃຈ. ກຸນແຈສໍາລັບມູນຄ່າຂອງການພິມແບບຄົງທີ່ແມ່ນຂະຫນາດຂອງການແກ້ໄຂ: ໂຄງການຂອງທ່ານໃຫຍ່ກວ່າ, ຫຼາຍທ່ານອີງໃສ່ການພິມແບບຄົງທີ່, ແລະໃນທີ່ສຸດ, ທ່ານຕ້ອງການມັນຫຼາຍ.

ສົມມຸດວ່າໂຄງການສະເພາະໃດຫນຶ່ງໄດ້ບັນລຸຂະຫນາດຂອງສິບພັນສາຍ, ແລະມັນໄດ້ຫັນອອກວ່ານັກຂຽນໂປລແກລມຈໍານວນຫນຶ່ງກໍາລັງເຮັດວຽກກັບມັນ. ຊອກຫາໂຄງການທີ່ຄ້າຍຄືກັນ, ອີງຕາມປະສົບການຂອງພວກເຮົາ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າການເຂົ້າໃຈລະຫັດຂອງມັນຈະເປັນກຸນແຈສໍາຄັນໃນການຮັກສານັກພັດທະນາ. ໂດຍບໍ່ມີຄໍາບັນຍາຍປະເພດ, ມັນສາມາດເປັນການຍາກທີ່ຈະຄິດອອກ, ຕົວຢ່າງ, ການໂຕ້ແຍ້ງໃດທີ່ຈະສົ່ງຕໍ່ກັບຟັງຊັນ, ຫຼືປະເພດຫນ້າທີ່ໃດທີ່ສາມາດກັບຄືນມາໄດ້. ນີ້ແມ່ນຄຳຖາມທົ່ວໄປທີ່ມັກຈະຕອບໄດ້ຍາກໂດຍບໍ່ຕ້ອງໃຊ້ຄຳອະທິບາຍປະເພດ:

• ຟັງຊັນນີ້ກັບຄືນມາໄດ້ None?
• ການໂຕ້ຖຽງນີ້ຄວນຈະເປັນແນວໃດ? items?
• ປະເພດຄຸນລັກສະນະແມ່ນຫຍັງ id: int ມັນ​ແມ່ນ, str, ຫຼືບາງປະເພດທີ່ກໍາຫນົດເອງ?
• ການໂຕ້ຖຽງນີ້ຄວນຈະເປັນບັນຊີລາຍຊື່ບໍ? ມັນເປັນໄປໄດ້ທີ່ຈະຜ່ານ tuple ກັບມັນບໍ?

ຖ້າທ່ານເບິ່ງ snippet ລະຫັດປະເພດຕໍ່ໄປນີ້ແລະພະຍາຍາມຕອບຄໍາຖາມທີ່ຄ້າຍຄືກັນ, ມັນຈະປາກົດວ່ານີ້ແມ່ນວຽກທີ່ງ່າຍດາຍທີ່ສຸດ:

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

• read_metadata ບໍ່ກັບຄືນມາ None, ນັບຕັ້ງແຕ່ປະເພດກັບຄືນບໍ່ແມ່ນ Optional[…].
• ການໂຕ້ຖຽງ items ແມ່ນລໍາດັບຂອງສາຍ. ມັນ​ບໍ່​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ທົດ​ສອບ​ໂດຍ​ສຸ່ມ​.
• ຄຸນລັກສະນະ id ແມ່ນສາຍຂອງ bytes.

ໃນໂລກທີ່ເຫມາະສົມ, ຄົນເຮົາຄາດຫວັງວ່າ subtleties ດັ່ງກ່າວທັງຫມົດຈະຖືກອະທິບາຍໄວ້ໃນເອກະສານທີ່ສ້າງຂຶ້ນ (docstring). ແຕ່ປະສົບການໃຫ້ຕົວຢ່າງຫຼາຍຢ່າງຂອງຄວາມຈິງທີ່ວ່າເອກະສານດັ່ງກ່າວມັກຈະບໍ່ສັງເກດເຫັນໃນລະຫັດທີ່ທ່ານຕ້ອງເຮັດວຽກ. ເຖິງແມ່ນວ່າເອກະສານດັ່ງກ່າວມີຢູ່ໃນລະຫັດ, ຄົນເຮົາບໍ່ສາມາດນັບໄດ້ກ່ຽວກັບຄວາມຖືກຕ້ອງຢ່າງແທ້ຈິງຂອງມັນ. ເອກະສານນີ້ສາມາດບໍ່ຈະແຈ້ງ, ບໍ່ຖືກຕ້ອງ, ແລະເປີດໃຫ້ເຂົ້າໃຈຜິດ. ໃນທີມງານຂະຫນາດໃຫຍ່ຫຼືໂຄງການຂະຫນາດໃຫຍ່, ບັນຫານີ້ສາມາດກາຍເປັນສ້ວຍແຫຼມທີ່ສຸດ.

ໃນຂະນະທີ່ Python ດີເລີດໃນຂັ້ນຕອນຕົ້ນຫຼືໄລຍະກາງຂອງໂຄງການ, ໃນບາງຈຸດທີ່ປະສົບຜົນສໍາເລັດໂຄງການແລະບໍລິສັດທີ່ໃຊ້ Python ອາດຈະປະເຊີນກັບຄໍາຖາມທີ່ສໍາຄັນ: "ພວກເຮົາຄວນຂຽນຄືນທຸກສິ່ງທຸກຢ່າງໃນພາສາທີ່ພິມສະຖິຕິ?".

ລະບົບການກວດສອບປະເພດເຊັ່ນ mypy ແກ້ໄຂບັນຫາຂ້າງເທິງໂດຍການໃຫ້ນັກພັດທະນາເປັນພາສາທີ່ເປັນທາງການສໍາລັບການອະທິບາຍປະເພດ, ແລະໂດຍການກວດສອບການປະກາດປະເພດນັ້ນກົງກັບການປະຕິບັດໂຄງການ (ແລະ, ທາງເລືອກ, ໂດຍການກວດສອບການມີຢູ່ຂອງມັນ). ໂດຍທົ່ວໄປແລ້ວ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າລະບົບເຫຼົ່ານີ້ເຮັດໃຫ້ພວກເຮົາກໍາຈັດບາງສິ່ງບາງຢ່າງເຊັ່ນ: ເອກະສານທີ່ຖືກກວດສອບຢ່າງລະມັດລະວັງ.

ການ​ນໍາ​ໃຊ້​ລະ​ບົບ​ດັ່ງ​ກ່າວ​ມີ​ຄວາມ​ໄດ້​ປຽບ​ອື່ນໆ​, ແລະ​ພວກ​ເຂົາ​ເຈົ້າ​ແມ່ນ​ແລ້ວ​ບໍ່​ແມ່ນ trivial​:

• ລະບົບການກວດສອບປະເພດສາມາດກວດພົບບາງຂໍ້ຜິດພາດ (ແລະບໍ່ນ້ອຍ). ຕົວຢ່າງປົກກະຕິແມ່ນເມື່ອພວກເຂົາລືມການປະມວນຜົນຄ່າ None ຫຼືບາງເງື່ອນໄຂພິເສດອື່ນໆ.
• ການແກ້ໄຂລະຫັດແມ່ນງ່າຍດາຍຫຼາຍເພາະວ່າລະບົບການກວດສອບປະເພດມັກຈະຖືກຕ້ອງຫຼາຍກ່ຽວກັບສິ່ງທີ່ລະຫັດຕ້ອງມີການປ່ຽນແປງ. ໃນເວລາດຽວກັນ, ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງຫວັງວ່າການຄຸ້ມຄອງລະຫັດ 100% ກັບການທົດສອບ, ເຊິ່ງ, ໃນກໍລະນີໃດກໍ່ຕາມ, ປົກກະຕິແລ້ວແມ່ນບໍ່ເປັນໄປໄດ້. ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງເຈາະເລິກເຂົ້າໄປໃນຄວາມເລິກຂອງການຕິດຕາມ stack ເພື່ອຊອກຫາສາເຫດຂອງບັນຫາ.
• ເຖິງແມ່ນວ່າຢູ່ໃນໂຄງການຂະຫນາດໃຫຍ່, mypy ມັກຈະສາມາດກວດສອບປະເພດເຕັມໃນແຕ່ສ່ວນຫນຶ່ງຂອງວິນາທີ. ແລະການປະຕິບັດການທົດສອບປົກກະຕິແລ້ວໃຊ້ເວລາສິບວິນາທີຫຼືແມ້ກະທັ້ງນາທີ. ລະບົບການກວດສອບປະເພດໃຫ້ຄໍາຄິດເຫັນຂອງນັກຂຽນໂປລແກລມທັນທີແລະຊ່ວຍໃຫ້ລາວເຮັດວຽກໄດ້ໄວຂຶ້ນ. ລາວບໍ່ຈໍາເປັນຕ້ອງຂຽນທີ່ອ່ອນແອແລະຍາກທີ່ຈະຮັກສາການທົດສອບຫນ່ວຍງານທີ່ປ່ຽນແທນຫນ່ວຍງານທີ່ແທ້ຈິງດ້ວຍການເຍາະເຍີ້ຍແລະ patches ພຽງແຕ່ເພື່ອໃຫ້ໄດ້ຜົນການທົດສອບລະຫັດໄວຂຶ້ນ.

IDEs ແລະບັນນາທິການເຊັ່ນ PyCharm ຫຼື Visual Studio Code ໃຊ້ອໍານາດຂອງຄໍາບັນຍາຍປະເພດເພື່ອໃຫ້ນັກພັດທະນາມີລະຫັດສໍາເລັດ, ການເນັ້ນຄວາມຜິດພາດ, ແລະສະຫນັບສະຫນູນໂຄງສ້າງພາສາທີ່ໃຊ້ທົ່ວໄປ. ແລະເຫຼົ່ານີ້ແມ່ນພຽງແຕ່ບາງສ່ວນຂອງຜົນປະໂຫຍດຂອງການພິມ. ສໍາລັບນັກຂຽນໂປລແກລມບາງຄົນ, ທັງຫມົດນີ້ແມ່ນການໂຕ້ຖຽງຕົ້ນຕໍໃນເງື່ອນໄຂຂອງການພິມ. ນີ້ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ໄດ້ຮັບຜົນປະໂຫຍດທັນທີຫຼັງຈາກການປະຕິບັດ. ກໍລະນີການນໍາໃຊ້ສໍາລັບປະເພດນີ້ບໍ່ຈໍາເປັນຕ້ອງມີລະບົບການກວດສອບປະເພດແຍກຕ່າງຫາກເຊັ່ນ mypy, ເຖິງແມ່ນວ່າມັນຄວນຈະສັງເກດວ່າ mypy ຊ່ວຍໃຫ້ຄໍາບັນຍາຍປະເພດສອດຄ່ອງກັບລະຫັດ.

ຄວາມເປັນມາຂອງ mypy

ປະຫວັດຂອງ mypy ໄດ້ເລີ່ມຕົ້ນໃນອັງກິດ, ໃນ Cambridge, ສອງສາມປີກ່ອນຂ້ອຍເຂົ້າຮ່ວມ Dropbox. ຂ້າພະເຈົ້າໄດ້ມີສ່ວນຮ່ວມ, ເປັນສ່ວນຫນຶ່ງຂອງການຄົ້ນຄວ້າປະລິນຍາເອກຂອງຂ້າພະເຈົ້າ, ໃນການປະສົມປະສານຂອງພາສາທີ່ພິມແບບຄົງທີ່ແລະແບບເຄື່ອນໄຫວ. ຂ້ອຍໄດ້ຮັບແຮງບັນດານໃຈຈາກບົດຄວາມກ່ຽວກັບການພິມເທື່ອລະກ້າວໂດຍ Jeremy Siek ແລະ Walid Taha, ແລະໂດຍໂຄງການ Typed Racket. ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມຊອກຫາວິທີການນໍາໃຊ້ພາສາການຂຽນໂປລແກລມດຽວກັນສໍາລັບໂຄງການຕ່າງໆ - ຈາກສະຄິບຂະຫນາດນ້ອຍໄປຫາຖານລະຫັດທີ່ປະກອບດ້ວຍຫຼາຍລ້ານສາຍ. ໃນຂະນະດຽວກັນ, ຂ້າພະເຈົ້າຕ້ອງການຮັບປະກັນວ່າໃນໂຄງການຂະຫນາດໃດກໍ່ຕາມ, ຫນຶ່ງຈະບໍ່ຕ້ອງເຮັດການປະນີປະນອມໃຫຍ່ເກີນໄປ. ພາກສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງສິ່ງທັງຫມົດນີ້ແມ່ນຄວາມຄິດຂອງຄ່ອຍໆຍ້າຍຈາກໂຄງການຕົ້ນແບບທີ່ບໍ່ໄດ້ພິມໄປສູ່ຜະລິດຕະພັນສໍາເລັດຮູບທີ່ພິມດ້ວຍສະຖິຕິທີ່ມີການທົດສອບທີ່ສົມບູນແບບ. ໃນມື້ນີ້, ແນວຄວາມຄິດເຫຼົ່ານີ້ແມ່ນໄດ້ຮັບການຍອມຮັບເປັນສ່ວນໃຫຍ່, ແຕ່ໃນປີ 2010 ມັນເປັນບັນຫາທີ່ຍັງໄດ້ຮັບການຄົ້ນຄ້ວາຢ່າງຈິງຈັງ.

ການເຮັດວຽກຕົ້ນສະບັບຂອງຂ້ອຍໃນການກວດສອບປະເພດບໍ່ໄດ້ແນໃສ່ Python. ແທນທີ່ຈະ, ຂ້ອຍໃຊ້ພາສາ "homemade" ຂະຫນາດນ້ອຍ Alore. ນີ້ແມ່ນຕົວຢ່າງທີ່ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈສິ່ງທີ່ພວກເຮົາເວົ້າກ່ຽວກັບ (ຄໍາບັນຍາຍປະເພດແມ່ນທາງເລືອກທີ່ນີ້):

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

ການນໍາໃຊ້ພາສາພື້ນເມືອງທີ່ງ່າຍດາຍແມ່ນວິທີການທົ່ວໄປທີ່ໃຊ້ໃນການຄົ້ນຄວ້າວິທະຍາສາດ. ນີ້ແມ່ນດັ່ງນັ້ນ, ບໍ່ແມ່ນຢ່າງຫນ້ອຍເນື່ອງຈາກວ່າມັນຊ່ວຍໃຫ້ທ່ານສາມາດດໍາເນີນການທົດລອງໄດ້ໄວ, ແລະຍັງເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າສິ່ງທີ່ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບການສຶກສາສາມາດຖືກລະເລີຍໄດ້ຢ່າງງ່າຍດາຍ. ພາສາການຂຽນໂປຼແກຼມໃນໂລກທີ່ແທ້ຈິງມີແນວໂນ້ມທີ່ຈະເປັນປະກົດການຂະຫນາດໃຫຍ່ທີ່ມີການປະຕິບັດທີ່ສັບສົນ, ແລະນີ້ເຮັດໃຫ້ການທົດລອງຊ້າລົງ. ຢ່າງໃດກໍ່ຕາມ, ຜົນໄດ້ຮັບໃດໆໂດຍອີງໃສ່ພາສາທີ່ງ່າຍດາຍເບິ່ງຄືວ່າມີຄວາມສົງໃສເລັກນ້ອຍ, ເພາະວ່າການໄດ້ຮັບຜົນໄດ້ຮັບເຫຼົ່ານີ້, ນັກຄົ້ນຄວ້າອາດຈະໄດ້ເສຍສະລະພິຈາລະນາທີ່ສໍາຄັນສໍາລັບການນໍາໃຊ້ພາສາຕົວຈິງ.

ຕົວກວດສອບປະເພດຂອງຂ້ອຍສໍາລັບ Alore ເບິ່ງຄືວ່າມີແນວໂນ້ມຫຼາຍ, ແຕ່ຂ້ອຍຕ້ອງການທົດສອບມັນໂດຍການທົດລອງກັບລະຫັດທີ່ແທ້ຈິງ, ເຊິ່ງ, ທ່ານອາດຈະເວົ້າວ່າ, ບໍ່ໄດ້ຂຽນໃນ Alore. ໂຊກດີສໍາລັບຂ້ອຍ, ພາສາ Alore ສ່ວນໃຫຍ່ແມ່ນອີງໃສ່ແນວຄວາມຄິດດຽວກັນກັບ Python. ມັນງ່າຍພໍທີ່ຈະເຮັດເຄື່ອງກວດພິມຄືນໃໝ່ເພື່ອໃຫ້ມັນສາມາດເຮັດວຽກໄດ້ກັບໄວຍະກອນ ແລະຄຳສັບຂອງ Python. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາພະຍາຍາມພິມການກວດສອບໃນລະຫັດ Python ແຫຼ່ງເປີດ. ນອກຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຂຽນ transpiler ເພື່ອປ່ຽນລະຫັດທີ່ຂຽນໃນ Alore ເປັນລະຫັດ Python ແລະໃຊ້ມັນເພື່ອແປລະຫັດ typechecker ຂອງຂ້ອຍ. ດຽວນີ້ຂ້ອຍມີລະບົບການກວດສອບປະເພດທີ່ຂຽນໃນ Python ທີ່ຮອງຮັບຊຸດຍ່ອຍຂອງ Python, ບາງພາສານັ້ນ! (ການຕັດສິນໃຈສະຖາປັດຕະຍະກໍາບາງຢ່າງທີ່ມີຄວາມຫມາຍສໍາລັບ Alore ແມ່ນບໍ່ດີພໍສໍາລັບ Python, ແລະນີ້ຍັງສັງເກດເຫັນຢູ່ໃນບາງສ່ວນຂອງ mypy codebase.)

ໃນຄວາມເປັນຈິງ, ພາສາທີ່ສະຫນັບສະຫນູນໂດຍລະບົບປະເພດຂອງຂ້ອຍບໍ່ສາມາດຖືກເອີ້ນວ່າ Python ໃນຈຸດນີ້: ມັນແມ່ນຕົວແປຂອງ Python ເນື່ອງຈາກຂໍ້ຈໍາກັດບາງຢ່າງຂອງ syntax ປະເພດ Python 3.

ມັນຄ້າຍຄືການປະສົມຂອງ Java ແລະ Python:

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

ຫນຶ່ງໃນຄວາມຄິດຂອງຂ້ອຍໃນເວລານັ້ນແມ່ນການໃຊ້ຄໍາບັນຍາຍປະເພດເພື່ອປັບປຸງການປະຕິບັດໂດຍການລວບລວມປະເພດຂອງ Python ນີ້ໄປຫາ C, ຫຼືບາງທີ JVM bytecode. ຂ້ອຍມາຮອດຂັ້ນຕອນຂອງການຂຽນຕົວແບບ compiler, ແຕ່ຂ້ອຍປະຖິ້ມຄວາມຄິດນີ້, ນັບຕັ້ງແຕ່ການກວດສອບປະເພດຕົວມັນເອງເບິ່ງຄືວ່າມີປະໂຫຍດຫຼາຍ.

ຂ້າພະເຈົ້າໄດ້ສິ້ນສຸດການນໍາສະເຫນີໂຄງການຂອງຂ້ອຍຢູ່ທີ່ PyCon 2013 ໃນ Santa Clara. ຂ້າພະເຈົ້າຍັງໄດ້ສົນທະນາກ່ຽວກັບເລື່ອງນີ້ກັບ Guido van Rossum, ຜູ້ບັນຊາການ Python ທີ່ໃຈດີຕະຫຼອດຊີວິດ. ລາວໄດ້ຊັກຊວນໃຫ້ຂ້ອຍລົງ syntax ຂອງຂ້ອຍເອງແລະຕິດກັບ syntax ມາດຕະຖານ Python 3. Python 3 ສະຫນັບສະຫນູນຄໍາອະທິບາຍກ່ຽວກັບຫນ້າທີ່, ດັ່ງນັ້ນຕົວຢ່າງຂອງຂ້ອຍສາມາດຖືກຂຽນຄືນໃຫມ່ຕາມຮູບຂ້າງລຸ່ມນີ້, ສົ່ງຜົນໃຫ້ໂຄງການ Python ປົກກະຕິ:

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

ຂ້ອຍຕ້ອງເຮັດການປະນີປະນອມບາງຢ່າງ (ກ່ອນອື່ນ ໝົດ, ຂ້ອຍຢາກສັງເກດວ່າຂ້ອຍໄດ້ປະດິດ syntax ຂອງຂ້ອຍເອງດ້ວຍເຫດຜົນນີ້). ໂດຍສະເພາະ, Python 3.3, ເວີຊັນຫຼ້າສຸດຂອງພາສາໃນເວລານັ້ນ, ບໍ່ສະຫນັບສະຫນູນຄໍາບັນຍາຍທີ່ປ່ຽນແປງໄດ້. ຂ້າພະເຈົ້າໄດ້ປຶກສາຫາລືກັບ Guido ໂດຍທາງອີເມລ໌ຄວາມເປັນໄປໄດ້ຕ່າງໆສໍາລັບການອອກແບບ syntactic ຂອງຄໍາບັນຍາຍດັ່ງກ່າວ. ພວກເຮົາໄດ້ຕັດສິນໃຈໃຊ້ຄໍາຄິດຄໍາເຫັນປະເພດສໍາລັບຕົວແປ. ອັນນີ້ໃຊ້ໄດ້ຕາມຈຸດປະສົງທີ່ຕັ້ງໄວ້, ແຕ່ກໍ່ເປັນເລື່ອງທີ່ສັບສົນ (Python 3.6 ໃຫ້ພວກເຮົາເປັນ syntax ທີ່ດີກວ່າ):

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

ຄຳເຫັນປະເພດຍັງມາພ້ອມເພື່ອຮອງຮັບ Python 2, ເຊິ່ງບໍ່ມີການຮອງຮັບໃນຕົວສຳລັບຄຳບັນຍາຍປະເພດ:

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

ມັນໄດ້ຫັນອອກວ່າການຄ້າເຫຼົ່ານີ້ (ແລະອື່ນໆ) ບໍ່ສໍາຄັນ - ຜົນປະໂຫຍດຂອງການພິມແບບຄົງທີ່ຫມາຍຄວາມວ່າຜູ້ໃຊ້ທັນທີລືມກ່ຽວກັບ syntax ຫນ້ອຍກວ່າທີ່ເຫມາະສົມ. ເນື່ອງຈາກບໍ່ມີໂຄງສ້າງ syntactic ພິເສດໄດ້ຖືກນໍາໃຊ້ໃນລະຫັດ Python ທີ່ມີການກວດສອບປະເພດ, ເຄື່ອງມື Python ທີ່ມີຢູ່ແລ້ວແລະຂະບວນການປຸງແຕ່ງລະຫັດຍັງສືບຕໍ່ເຮັດວຽກເປັນປົກກະຕິ, ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນຫຼາຍສໍາລັບນັກພັດທະນາທີ່ຈະຮຽນຮູ້ເຄື່ອງມືໃຫມ່.

Guido ຍັງໄດ້ຊັກຊວນໃຫ້ຂ້ອຍເຂົ້າຮ່ວມ Dropbox ຫຼັງຈາກຂ້ອຍເຮັດທິດສະດີຈົບການສຶກສາຂອງຂ້ອຍ. ນີ້ແມ່ນບ່ອນທີ່ສ່ວນທີ່ຫນ້າສົນໃຈທີ່ສຸດຂອງເລື່ອງ mypy ເລີ່ມຕົ້ນ.

ຕິດ​ຕາມ​ຕອນ​ຕໍ່​ໄປ…

ທ່ານຜູ້ອ່ານທີ່ຮັກແພງ! ຖ້າທ່ານໃຊ້ Python, ກະລຸນາບອກພວກເຮົາກ່ຽວກັບຂະຫນາດຂອງໂຄງການທີ່ທ່ານພັດທະນາໃນພາສານີ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com