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

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

→ ອ່ານສ່ວນຫນຶ່ງ

ສະຫນັບສະຫນູນປະເພດຢ່າງເປັນທາງການ (PEP 484)

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

ໃນເວລານັ້ນ, ແນວຄວາມຄິດຂອງມາດຕະຖານລະບົບ hinting ປະເພດ Python ແມ່ນຢູ່ໃນອາກາດ. ດັ່ງທີ່ຂ້າພະເຈົ້າເວົ້າ, ນັບຕັ້ງແຕ່ Python 3.0 ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ຄໍາບັນຍາຍປະເພດສໍາລັບຫນ້າທີ່, ແຕ່ເຫຼົ່ານີ້ແມ່ນພຽງແຕ່ການສະແດງອອກໂດຍຕົນເອງ, ໂດຍບໍ່ມີການກໍານົດ syntax ແລະ semantics. ໃນ​ລະ​ຫວ່າງ​ການ​ປະ​ຕິ​ບັດ​ໂຄງ​ການ, ຄໍາ​ອະ​ທິ​ບາຍ​ເຫຼົ່າ​ນີ້, ສໍາ​ລັບ​ພາກ​ສ່ວນ​ຫຼາຍ, ພຽງ​ແຕ່​ລະ​ເລີຍ. ຫຼັງຈາກອາທິດ Hack, ພວກເຮົາໄດ້ເລີ່ມເຮັດວຽກກ່ຽວກັບການສ້າງມາດຕະຖານຄວາມຫມາຍ. ວຽກງານນີ້ນໍາໄປສູ່ການເກີດຂື້ນ ປປ 484 (Guido van Rossum, Łukasz Langa ແລະຂ້າພະເຈົ້າໄດ້ຮ່ວມມືໃນເອກະສານນີ້).

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

syntax hint ປະເພດທີ່ໄດ້ຖືກຮັບຮອງເອົາໃນທີ່ສຸດແມ່ນຄ້າຍຄືກັນກັບສິ່ງທີ່ mypy ສະຫນັບສະຫນູນໃນເວລານັ້ນ. PEP 484 ຖືກປ່ອຍອອກມາດ້ວຍ Python 3.5 ໃນປີ 2015. Python ບໍ່ແມ່ນພາສາທີ່ພິມແບບໄດນາມິກອີກຕໍ່ໄປ. ຂ້າພະເຈົ້າມັກຄິດວ່າເຫດການນີ້ເປັນເຫດການສໍາຄັນໃນປະຫວັດສາດ Python.

ການເລີ່ມຕົ້ນຂອງການເຄື່ອນຍ້າຍ

ໃນຕອນທ້າຍຂອງ 2015, Dropbox ໄດ້ສ້າງທີມງານສາມຄົນເພື່ອເຮັດວຽກກ່ຽວກັບ mypy. ພວກເຂົາປະກອບມີ Guido van Rossum, Greg Price ແລະ David Fisher. ຕັ້ງແຕ່ນັ້ນມາ, ສະຖານະການເລີ່ມພັດທະນາຢ່າງໄວວາ. ອຸປະສັກທໍາອິດຕໍ່ການເຕີບໂຕຂອງ mypy ແມ່ນການປະຕິບັດ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ບອກໄວ້ຂ້າງເທິງ, ໃນຕອນຕົ້ນຂອງໂຄງການ, ຂ້າພະເຈົ້າໄດ້ຄິດກ່ຽວກັບການແປການປະຕິບັດ mypy ເປັນ C, ແຕ່ແນວຄວາມຄິດນີ້ໄດ້ຖືກຂ້າມອອກຈາກບັນຊີລາຍຊື່ໃນປັດຈຸບັນ. ພວກເຮົາຕິດຢູ່ກັບການເຮັດວຽກຂອງລະບົບໂດຍໃຊ້ຕົວແປພາສາ CPython, ເຊິ່ງບໍ່ໄວພໍສໍາລັບເຄື່ອງມືເຊັ່ນ mypy. (ໂຄງການ PyPy, ການປະຕິບັດທາງເລືອກ Python ກັບ compiler JIT, ບໍ່ໄດ້ຊ່ວຍພວກເຮົາຄືກັນ.)

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

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

ນີ້​ແມ່ນ​ໄລ​ຍະ​ເວ​ລາ​ຂອງ​ການ​ຮັບ​ຮອງ​ເອົາ​ຢ່າງ​ວ່ອງ​ໄວ​ແລະ​ທໍາ​ມະ​ຊາດ​ຂອງ​ການ​ກວດ​ສອບ​ປະ​ເພດ​ຢູ່ Dropbox​. ໃນຕອນທ້າຍຂອງ 2016, ພວກເຮົາມີປະມານ 420000 ເສັ້ນຂອງລະຫັດ Python ທີ່ມີຄໍາບັນຍາຍປະເພດ. ຜູ້ໃຊ້ຫຼາຍຄົນກະຕືລືລົ້ນໃນການກວດສອບປະເພດ. ທີມງານພັດທະນາຫຼາຍກວ່າແລະຫຼາຍໄດ້ໃຊ້ Dropbox mypy.

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

ຜົນຜະລິດຫຼາຍ!

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

ພວກເຮົາໄດ້ພິຈາລະນາຄວາມເປັນໄປໄດ້ຂອງ "untangling" ການຂຶ້ນກັບວົງ, ແຕ່ພວກເຮົາບໍ່ມີຊັບພະຍາກອນທີ່ຈະເຮັດມັນ. ມີລະຫັດຫຼາຍເກີນໄປທີ່ພວກເຮົາບໍ່ຄຸ້ນເຄີຍກັບ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ມາເຖິງວິທີການທາງເລືອກ. ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ເຮັດ​ໃຫ້ mypy ເຮັດ​ວຽກ​ຢ່າງ​ວ່ອງ​ໄວ​ເຖິງ​ແມ່ນ​ວ່າ​ຢູ່​ໃນ​ທີ່​ປະ​ທັບ​ຂອງ “tangles dependency”. ພວກເຮົາໄດ້ບັນລຸເປົ້າຫມາຍນີ້ໂດຍໃຊ້ mypy daemon. daemon ແມ່ນຂະບວນການເຊີຟເວີທີ່ປະຕິບັດສອງລັກສະນະທີ່ຫນ້າສົນໃຈ. ທໍາອິດ, ມັນເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບ codebase ທັງຫມົດໃນຫນ່ວຍຄວາມຈໍາ. ນີ້ຫມາຍຄວາມວ່າທຸກຄັ້ງທີ່ທ່ານດໍາເນີນການ mypy, ທ່ານບໍ່ຈໍາເປັນຕ້ອງໂຫລດຂໍ້ມູນຈາກຖານຄວາມຈໍາທີ່ກ່ຽວຂ້ອງກັບພັນຂອງ dependencies ນໍາເຂົ້າ. ອັນທີສອງ, ລາວລະມັດລະວັງ, ໃນລະດັບຂອງຫນ່ວຍງານໂຄງສ້າງຂະຫນາດນ້ອຍ, ວິເຄາະຄວາມເພິ່ງພາອາໄສລະຫວ່າງຫນ້າທີ່ແລະຫນ່ວຍງານອື່ນໆ. ຕົວຢ່າງ, ຖ້າຫນ້າທີ່ foo ເອີ້ນຟັງຊັນ bar, ຫຼັງຈາກນັ້ນມີການເພິ່ງພາອາໄສ foo ຈາກ bar. ເມື່ອໄຟລ໌ປ່ຽນແປງ, daemon ທໍາອິດ, ໃນການໂດດດ່ຽວ, ດໍາເນີນການພຽງແຕ່ໄຟລ໌ທີ່ມີການປ່ຽນແປງ. ຈາກນັ້ນມັນເບິ່ງການປ່ຽນແປງທີ່ເຫັນໄດ້ຈາກພາຍນອກຂອງໄຟລ໌ນັ້ນ, ເຊັ່ນ: ລາຍເຊັນຂອງຫນ້າທີ່ມີການປ່ຽນແປງ. daemon ໃຊ້ຂໍ້ມູນລະອຽດກ່ຽວກັບການນໍາເຂົ້າພຽງແຕ່ການກວດສອບສອງຄັ້ງທີ່ຟັງຊັນທີ່ໃຊ້ໃນຕົວຈິງແລ້ວ. ໂດຍປົກກະຕິ, ດ້ວຍວິທີການນີ້, ທ່ານຕ້ອງກວດເບິ່ງຫນ້າທີ່ຫນ້ອຍທີ່ສຸດ.

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

ຜົນຜະລິດຫຼາຍຂຶ້ນ!

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

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

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

compiler, ທີ່ພວກເຮົາເອີ້ນວ່າ mypyc (ນັບຕັ້ງແຕ່ມັນໃຊ້ mypy ເປັນ front-end ສໍາລັບການວິເຄາະປະເພດ), ໄດ້ກາຍເປັນໂຄງການສົບຜົນສໍາເລັດຫຼາຍ. ໂດຍລວມແລ້ວ, ພວກເຮົາບັນລຸໄດ້ປະມານ 4x speedup ສໍາລັບການແລ່ນ mypy ເລື້ອຍໆໂດຍບໍ່ມີການຖານຄວາມຈໍາ. ການພັດທະນາຫຼັກຂອງໂຄງການ mypyc ໄດ້ໃຊ້ເວລາທີມງານຂະຫນາດນ້ອຍຂອງ Michael Sullivan, Ivan Levkivsky, Hugh Hahn, ແລະຕົນເອງປະມານ 4 ເດືອນປະຕິທິນ. ຈໍານວນວຽກງານນີ້ແມ່ນນ້ອຍກວ່າສິ່ງທີ່ຕ້ອງການເພື່ອຂຽນ mypy ຄືນໃໝ່, ຕົວຢ່າງ, ໃນ C++ ຫຼື Go. ແລະພວກເຮົາຕ້ອງເຮັດການປ່ຽນແປງໂຄງການຫນ້ອຍກວ່າທີ່ພວກເຮົາຕ້ອງເຮັດໃນເວລາທີ່ຂຽນໃຫມ່ໃນພາສາອື່ນ. ພວກເຮົາຍັງຫວັງວ່າພວກເຮົາສາມາດນໍາ mypyc ໄປສູ່ລະດັບທີ່ນັກຂຽນໂປລແກລມ Dropbox ອື່ນໆສາມາດໃຊ້ມັນເພື່ອລວບລວມແລະເລັ່ງລະຫັດຂອງພວກເຂົາ.

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

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

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

ທ່ານຜູ້ອ່ານທີ່ຮັກແພງ! ແມ່ນຫຍັງຄືຄວາມປະທັບໃຈຂອງເຈົ້າຕໍ່ໂຄງການ mypy ໃນເວລາທີ່ທ່ານໄດ້ຮຽນຮູ້ເຖິງການມີຢູ່ຂອງມັນ?

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