ផ្លូវទៅកាន់ការវាយអក្សរ 4 លានបន្ទាត់នៃកូដ Python ។ ផ្នែកទី 2

ថ្ងៃនេះយើងកំពុងបោះពុម្ពផ្នែកទីពីរនៃការបកប្រែសម្ភារៈអំពីរបៀបដែល Dropbox បានរៀបចំការគ្រប់គ្រងប្រភេទសម្រាប់កូដ Python រាប់លានបន្ទាត់។

→ អានភាគមួយ។

ការគាំទ្រប្រភេទផ្លូវការ (PEP 484)

យើងបានធ្វើការពិសោធន៍ដ៏ធ្ងន់ធ្ងរលើកដំបូងរបស់យើងជាមួយ mypy នៅ Dropbox កំឡុងពេល Hack Week 2014 ។ Hack Week គឺជាព្រឹត្តិការណ៍មួយសប្តាហ៍ដែលរៀបចំដោយ Dropbox ។ ក្នុងអំឡុងពេលនេះ និយោជិតអាចធ្វើការលើអ្វីដែលខ្លួនចង់បាន! គម្រោងបច្ចេកវិទ្យាល្បីៗមួយចំនួនរបស់ Dropbox បានចាប់ផ្តើមនៅក្នុងព្រឹត្តិការណ៍បែបនេះ។ ជាលទ្ធផលនៃការពិសោធន៍នេះ យើងបានសន្និដ្ឋានថា mypy មើលទៅហាក់ដូចជាមានជោគជ័យ ទោះបីជាគម្រោងនេះមិនទាន់រួចរាល់សម្រាប់ការប្រើប្រាស់យ៉ាងទូលំទូលាយក៏ដោយ។

នៅពេលនោះ គំនិតនៃការកំណត់ស្តង់ដារប្រព័ន្ធជំនួយប្រភេទ Python គឺនៅលើអាកាស។ ដូចដែលខ្ញុំបាននិយាយ ចាប់តាំងពី Python 3.0 វាអាចប្រើប្រភេទចំណារពន្យល់សម្រាប់មុខងារ ប៉ុន្តែទាំងនេះគ្រាន់តែជាការបញ្ចេញមតិតាមអំពើចិត្ត ដោយគ្មានវាក្យសម្ព័ន្ធ និងអត្ថន័យដែលបានកំណត់។ ក្នុងអំឡុងពេលដំណើរការកម្មវិធី ចំណារពន្យល់ទាំងនេះភាគច្រើនត្រូវបានមិនអើពើ។ បន្ទាប់ពីសប្តាហ៍នៃការ Hack យើងបានចាប់ផ្តើមធ្វើការលើស្តង់ដារនៃន័យធៀប។ ការងារនេះបាននាំឱ្យមានការលេចឡើង ភី ៣១៣៦ (Guido van Rossum, Łukasz Langa និងខ្ញុំបានសហការគ្នាលើឯកសារនេះ)។

ការជម្រុញរបស់យើងអាចត្រូវបានមើលពីភាគីទាំងពីរ។ ជាដំបូង យើងសង្ឃឹមថាប្រព័ន្ធអេកូ Python ទាំងមូលអាចទទួលយកវិធីសាស្រ្តទូទៅក្នុងការប្រើការណែនាំប្រភេទ (ពាក្យដែលប្រើក្នុង Python ជាពាក្យដែលស្មើនឹង "ប្រភេទចំណារពន្យល់")។ នេះ​បើ​តាម​ការ​ប្រថុយប្រថាន​ដែល​អាច​កើត​មាន​បាន​ល្អ​ជាង​ការ​ប្រើ​វិធី​ដែល​មិន​ត្រូវ​គ្នា​ទៅ​វិញ​ទៅ​មក​ជា​ច្រើន។ ទីពីរ យើងចង់ពិភាក្សាដោយបើកចំហអំពីយន្តការចំណារពន្យល់ប្រភេទជាមួយសមាជិកជាច្រើននៃសហគមន៍ Python ។ បំណងប្រាថ្នានេះត្រូវបានកំណត់ដោយផ្នែកដោយការពិតដែលថាយើងមិនចង់មើលទៅដូចជា "អ្នកក្បត់សាសនា" ពីគំនិតជាមូលដ្ឋាននៃភាសានៅក្នុងភ្នែកនៃមហាជនទូលំទូលាយនៃអ្នកសរសេរកម្មវិធី Python ។ វា​គឺ​ជា​ភាសា​វាយ​អក្សរ​ថាមវន្ត ដែល​គេ​ស្គាល់​ថា​ជា "ការ​វាយ​បញ្ចូល​ទា"។ នៅក្នុងសហគមន៍នៅដើមដំបូងអាកប្បកិរិយាគួរឱ្យសង្ស័យចំពោះគំនិតនៃការវាយអក្សរឋិតិវន្តមិនអាចជួយបានទេប៉ុន្តែកើតឡើង។ ប៉ុន្តែ​អារម្មណ៍​នោះ​នៅ​ទី​បំផុត​បាន​រសាត់​ទៅ​វិញ​បន្ទាប់​ពី​វា​បាន​ច្បាស់​ថា​ការ​វាយ​អក្សរ​ឋិតិវន្ត​នឹង​មិន​ត្រូវ​បាន​បង្ខំ​ទេ (ហើយ​បន្ទាប់​ពី​មនុស្ស​បាន​ដឹង​ថា​វា​ពិត​ជា​មាន​ប្រយោជន៍)។

វាក្យសម្ព័ន្ធជំនួយប្រភេទដែលត្រូវបានអនុម័តនៅទីបំផុតគឺស្រដៀងទៅនឹងអ្វីដែល 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 ជាមួយនឹងកម្មវិធីចងក្រង JIT ក៏មិនបានជួយយើងដែរ។)

ជាសំណាងល្អ ការកែលម្អក្បួនដោះស្រាយមួយចំនួនបានមកដល់ជំនួយរបស់យើងនៅទីនេះ។ "ឧបករណ៍បង្កើនល្បឿន" ដ៏មានអានុភាពដំបូងគឺការអនុវត្តការត្រួតពិនិត្យបន្ថែម។ គំនិតនៅពីក្រោយការកែលម្អនេះគឺសាមញ្ញ៖ ប្រសិនបើភាពអាស្រ័យរបស់ម៉ូឌុលទាំងអស់មិនបានផ្លាស់ប្តូរចាប់តាំងពីការដំណើរការពីមុននៃ mypy នោះយើងអាចប្រើទិន្នន័យដែលបានរក្សាទុកក្នុងឃ្លាំងសម្ងាត់ក្នុងអំឡុងពេលដំណើរការមុនខណៈពេលដែលធ្វើការជាមួយភាពអាស្រ័យ។ យើងគ្រាន់តែត្រូវការដើម្បីធ្វើការត្រួតពិនិត្យប្រភេទលើឯកសារដែលបានកែប្រែ និងនៅលើឯកសារដែលពឹងផ្អែកលើពួកវា។ Mypy ថែមទាំងដើរទៅមុខបន្តិចទៀត៖ ប្រសិនបើចំណុចប្រទាក់ខាងក្រៅនៃម៉ូឌុលមិនផ្លាស់ប្តូរទេ mypy សន្មត់ថាម៉ូឌុលផ្សេងទៀតដែលនាំចូលម៉ូឌុលនេះមិនចាំបាច់ត្រូវពិនិត្យម្តងទៀតទេ។

ការត្រួតពិនិត្យបន្ថែមបានជួយយើងច្រើននៅពេលកំណត់ចំណាំចំនួនដ៏ច្រើននៃកូដដែលមានស្រាប់។ ចំណុចនោះគឺថា ដំណើរការនេះជាធម្មតាពាក់ព័ន្ធនឹងការដំណើរការ mypy ដដែលៗជាច្រើន ខណៈដែលចំណារពន្យល់ត្រូវបានបន្ថែមបន្តិចម្តងៗទៅក្នុងកូដ ហើយត្រូវបានកែលម្អបន្តិចម្តងៗ។ ការរត់ដំបូងរបស់ mypy នៅតែយឺតខ្លាំង ព្រោះវាមានភាពអាស្រ័យច្រើនក្នុងការត្រួតពិនិត្យ។ បន្ទាប់មក ដើម្បីកែលម្អស្ថានភាព យើងបានអនុវត្តយន្តការឃ្លាំងសម្ងាត់ពីចម្ងាយ។ ប្រសិនបើ mypy រកឃើញថាឃ្លាំងសម្ងាត់មូលដ្ឋានទំនងជាហួសសម័យ វាទាញយករូបថតឃ្លាំងសម្ងាត់បច្ចុប្បន្នសម្រាប់មូលដ្ឋានកូដទាំងមូលពីឃ្លាំងកណ្តាល។ បន្ទាប់មកវាធ្វើការត្រួតពិនិត្យបន្ថែមដោយប្រើរូបថតនេះ។ នេះបាននាំយើងនូវជំហានដ៏ធំមួយទៀតឆ្ពោះទៅរកការបង្កើនការអនុវត្តរបស់ mypy ។

នេះគឺជារយៈពេលនៃការទទួលយកយ៉ាងឆាប់រហ័ស និងធម្មជាតិនៃការត្រួតពិនិត្យប្រភេទនៅ Dropbox ។ នៅចុងឆ្នាំ 2016 យើងមានកូដ Python ប្រហែល 420000 បន្ទាត់រួចហើយ ជាមួយនឹងចំណារពន្យល់ប្រភេទ។ អ្នកប្រើប្រាស់ជាច្រើនបានសាទរចំពោះការពិនិត្យប្រភេទ។ ក្រុមអភិវឌ្ឍន៍កាន់តែច្រើនកំពុងប្រើ Dropbox mypy ។

អ្វីៗមើលទៅល្អនៅពេលនោះ ប៉ុន្តែយើងនៅមានរឿងជាច្រើនដែលត្រូវធ្វើ។ យើងបានចាប់ផ្តើមធ្វើការស្ទង់មតិអ្នកប្រើប្រាស់ផ្ទៃក្នុងតាមកាលកំណត់ដើម្បីកំណត់បញ្ហានៃគម្រោង និងស្វែងយល់ថាតើបញ្ហាអ្វីខ្លះដែលត្រូវដោះស្រាយជាមុនសិន (ការអនុវត្តនេះនៅតែត្រូវបានប្រើប្រាស់នៅក្នុងក្រុមហ៊ុនសព្វថ្ងៃនេះ)។ សំខាន់បំផុត ដូចដែលវាច្បាស់ហើយ គឺកិច្ចការពីរ។ ទីមួយ យើងត្រូវការប្រភេទគ្របដណ្តប់បន្ថែមទៀតនៃកូដ ទីពីរ យើងត្រូវការ mypy ដើម្បីដំណើរការលឿនជាងមុន។ វាច្បាស់ណាស់ថាការងាររបស់យើងដើម្បីបង្កើនល្បឿន mypy និងអនុវត្តវាទៅក្នុងគម្រោងរបស់ក្រុមហ៊ុនគឺនៅឆ្ងាយពីការពេញលេញនៅឡើយ។ យើងដឹងយ៉ាងច្បាស់អំពីសារៈសំខាន់នៃកិច្ចការទាំងពីរនេះ កំណត់អំពីការដោះស្រាយវា។

ផលិតភាពកាន់តែច្រើន!

ការត្រួតពិនិត្យបន្ថែមបានធ្វើឱ្យ mypy លឿនជាងមុន ប៉ុន្តែឧបករណ៍នៅតែមិនលឿនគ្រប់គ្រាន់។ ការត្រួតពិនិត្យបន្ថែមជាច្រើនមានរយៈពេលប្រហែលមួយនាទី។ មូលហេតុ​នេះ​គឺ​ការ​នាំ​ចូល​តាម​វដ្ត​។ នេះប្រហែលជាមិនភ្ញាក់ផ្អើលដល់នរណាម្នាក់ដែលបានធ្វើការជាមួយមូលដ្ឋានកូដធំដែលសរសេរនៅក្នុង Python នោះទេ។ យើងមានបណ្តុំនៃម៉ូឌុលរាប់រយ ដែលនីមួយៗបាននាំចូលដោយប្រយោលទាំងអស់ផ្សេងទៀត។ ប្រសិនបើឯកសារណាមួយនៅក្នុងរង្វិលជុំនាំចូលត្រូវបានផ្លាស់ប្តូរ mypy ត្រូវដំណើរការឯកសារទាំងអស់នៅក្នុងរង្វិលជុំនោះ ហើយជាញឹកញាប់ម៉ូឌុលណាមួយដែលបាននាំចូលម៉ូឌុលពីរង្វិលជុំនោះ។ វដ្តមួយបែបនេះគឺជា "ភាពច្របូកច្របល់នៃការពឹងផ្អែក" ដ៏អាក្រក់ដែលបណ្តាលឱ្យមានបញ្ហាជាច្រើននៅ Dropbox ។ នៅពេលដែលរចនាសម្ព័ន្ធនេះមានម៉ូឌុលរាប់រយ ខណៈពេលដែលវាត្រូវបាននាំចូលដោយផ្ទាល់ ឬដោយប្រយោល ការធ្វើតេស្តជាច្រើន វាក៏ត្រូវបានគេប្រើនៅក្នុងកូដផលិតកម្មផងដែរ។

យើង​បាន​ពិចារណា​អំពី​លទ្ធភាព​នៃ​ការ​ពឹងផ្អែក​រាងជារង្វង់ ប៉ុន្តែ​យើង​មិន​មាន​ធនធាន​ដើម្បី​ធ្វើ​វា​ទេ។ មានលេខកូដច្រើនពេកដែលយើងមិនធ្លាប់ស្គាល់។ ជាលទ្ធផល យើងបានបង្កើតវិធីសាស្រ្តជំនួស។ យើងបានសម្រេចចិត្តធ្វើឱ្យ mypy ធ្វើការយ៉ាងឆាប់រហ័ស សូម្បីតែនៅក្នុងវត្តមាននៃ "ការជាប់ពាក់ព័ន្ធ" ក៏ដោយ។ យើងបានសម្រេចគោលដៅនេះដោយប្រើដេមិន mypy ។ ដេមិនគឺជាដំណើរការម៉ាស៊ីនមេដែលអនុវត្តមុខងារគួរឱ្យចាប់អារម្មណ៍ពីរ។ ទីមួយ វាផ្ទុកព័ត៌មានអំពីមូលដ្ឋានកូដទាំងមូលនៅក្នុងអង្គចងចាំ។ នេះមានន័យថារាល់ពេលដែលអ្នកដំណើរការ mypy អ្នកមិនចាំបាច់ផ្ទុកទិន្នន័យក្នុងឃ្លាំងសម្ងាត់ដែលទាក់ទងនឹងភាពអាស្រ័យដែលបាននាំចូលរាប់ពាន់នោះទេ។ ទីពីរ គាត់ដោយប្រុងប្រយ័ត្ននៅកម្រិតនៃអង្គភាពរចនាសម្ព័ន្ធតូចៗ វិភាគភាពអាស្រ័យរវាងមុខងារ និងអង្គភាពផ្សេងទៀត។ ឧទាហរណ៍ប្រសិនបើមុខងារ foo ហៅមុខងារមួយ។ barបន្ទាប់មកមានការពឹងផ្អែក foo ពី bar. នៅពេលដែលឯកសារផ្លាស់ប្តូរ ដេមិនដំបូងនៅក្នុងភាពឯកោ ដំណើរការតែឯកសារដែលបានផ្លាស់ប្តូរប៉ុណ្ណោះ។ បន្ទាប់មកវាមើលការផ្លាស់ប្តូរដែលអាចមើលឃើញខាងក្រៅចំពោះឯកសារនោះ ដូចជាហត្ថលេខាមុខងារដែលបានផ្លាស់ប្តូរ។ ដេមិនប្រើព័ត៌មានលំអិតអំពីការនាំចូលតែប៉ុណ្ណោះ ដើម្បីពិនិត្យមើលមុខងារទាំងនោះដែលពិតជាប្រើមុខងារដែលបានកែប្រែ។ ជាធម្មតាជាមួយនឹងវិធីសាស្រ្តនេះ អ្នកត្រូវតែពិនិត្យមើលមុខងារតិចតួចបំផុត។

ការអនុវត្តទាំងអស់នេះគឺមិនមែនជាការងាយស្រួលនោះទេ ចាប់តាំងពីការអនុវត្ត mypy ដើមត្រូវបានផ្តោតយ៉ាងខ្លាំងលើដំណើរការឯកសារមួយក្នុងពេលតែមួយ។ យើងត្រូវដោះស្រាយជាមួយស្ថានភាពព្រំដែនជាច្រើន ការកើតឡើងដែលតម្រូវឱ្យមានការត្រួតពិនិត្យម្តងហើយម្តងទៀតក្នុងករណីដែលអ្វីមួយបានផ្លាស់ប្តូរនៅក្នុងកូដ។ ឧទាហរណ៍ វាកើតឡើងនៅពេលដែលថ្នាក់មួយត្រូវបានចាត់ថ្នាក់មូលដ្ឋានថ្មី។ នៅពេលដែលយើងធ្វើអ្វីដែលយើងចង់បាន យើងអាចកាត់បន្ថយពេលវេលានៃការត្រួតពិនិត្យបន្ថែមភាគច្រើនមកត្រឹមពីរបីវិនាទីប៉ុណ្ណោះ។ នេះ​ហាក់​ដូច​ជា​ជ័យ​ជម្នះ​ដ៏​ធំ​មួយ​សម្រាប់​យើង។

កាន់តែផលិតភាព!

រួមគ្នាជាមួយឃ្លាំងសម្ងាត់ពីចម្ងាយដែលខ្ញុំបានពិភាក្សាខាងលើ ដេមិន mypy ស្ទើរតែដោះស្រាយបញ្ហាដែលកើតឡើងនៅពេលដែលអ្នកសរសេរកម្មវិធីតែងតែដំណើរការការត្រួតពិនិត្យប្រភេទ ដោយធ្វើការផ្លាស់ប្តូរទៅឯកសារមួយចំនួនតូច។ ទោះជាយ៉ាងណាក៏ដោយ ដំណើរការប្រព័ន្ធនៅក្នុងករណីប្រើប្រាស់អំណោយផលតិចបំផុតគឺនៅតែឆ្ងាយពីភាពល្អប្រសើរបំផុត។ ការចាប់ផ្តើមស្អាតនៃ mypy អាចចំណាយពេលលើសពី 15 នាទី។ ហើយនេះគឺច្រើនជាងអ្វីដែលយើងនឹងសប្បាយចិត្ត។ ជារៀងរាល់សប្តាហ៍ ស្ថានភាពកាន់តែអាក្រក់ទៅៗ នៅពេលដែលអ្នកសរសេរកម្មវិធីបន្តសរសេរកូដថ្មី និងបន្ថែមចំណារពន្យល់ទៅកាន់កូដដែលមានស្រាប់។ អ្នកប្រើប្រាស់របស់យើងនៅតែស្រេកឃ្លានសម្រាប់ការអនុវត្តបន្ថែមទៀត ប៉ុន្តែយើងរីករាយដែលបានជួបពួកគេពាក់កណ្តាលផ្លូវ។

យើងបានសម្រេចចិត្តត្រលប់ទៅគំនិតមុនមួយទាក់ទងនឹង mypy ។ ពោលគឺដើម្បីបំប្លែងកូដ Python ទៅជាកូដ C ។ ការសាកល្បងជាមួយ Cython (ប្រព័ន្ធដែលអនុញ្ញាតឱ្យអ្នកបកប្រែកូដដែលសរសេរដោយ Python ទៅជាកូដ C) មិនបានផ្តល់ឱ្យយើងនូវល្បឿនដែលអាចមើលឃើញនោះទេ ដូច្នេះហើយយើងបានសម្រេចចិត្តរស់ឡើងវិញនូវគំនិតនៃការសរសេរកម្មវិធីចងក្រងផ្ទាល់ខ្លួនរបស់យើង។ ដោយសារ mypy codebase (សរសេរក្នុង Python) មានចំណារពន្យល់ប្រភេទចាំបាច់ទាំងអស់រួចហើយ យើងគិតថាវាពិតជាមានប្រយោជន៍ក្នុងការព្យាយាមប្រើចំណារពន្យល់ទាំងនេះដើម្បីបង្កើនល្បឿនប្រព័ន្ធ។ ខ្ញុំបានបង្កើតគំរូមួយយ៉ាងឆាប់រហ័ស ដើម្បីសាកល្បងគំនិតនេះ។ វាបានបង្ហាញពីការកើនឡើងច្រើនជាង 10 ដងក្នុងការអនុវត្តលើស្តង់ដារមីក្រូផ្សេងៗ។ គំនិតរបស់យើងគឺដើម្បីចងក្រងម៉ូឌុល Python ទៅជាម៉ូឌុល C ដោយប្រើ Cython និងដើម្បីបង្វែរចំណារពន្យល់ប្រភេទទៅជាការត្រួតពិនិត្យប្រភេទពេលដំណើរការ (ជាធម្មតា ចំណារពន្យល់ប្រភេទមិនត្រូវបានអើពើនៅពេលដំណើរការ ហើយប្រើតែដោយប្រព័ន្ធពិនិត្យប្រភេទប៉ុណ្ណោះ)។ យើងពិតជាមានគម្រោងបកប្រែការអនុវត្តន៍ mypy ពី Python ទៅជាភាសាដែលត្រូវបានរចនាឡើងដើម្បីវាយអក្សរជាស្ថាពរ ដែលនឹងមើលទៅ (ហើយភាគច្រើនធ្វើការ) ដូច Python ដែរ។ (ប្រភេទនៃការធ្វើចំណាកស្រុកឆ្លងភាសានេះបានក្លាយជាប្រពៃណីនៃគម្រោង mypy ។ ការអនុវត្ត mypy ដើមត្រូវបានសរសេរជា Alore បន្ទាប់មកមានកូនកាត់វាក្យសម្ព័ន្ធនៃ Java និង Python) ។

ការផ្តោតលើ API ផ្នែកបន្ថែម CPython គឺជាគន្លឹះក្នុងការមិនបាត់បង់សមត្ថភាពគ្រប់គ្រងគម្រោង។ យើងមិនចាំបាច់អនុវត្តម៉ាស៊ីននិម្មិត ឬបណ្ណាល័យណាមួយដែល mypy ត្រូវការនោះទេ។ លើសពីនេះ យើងនៅតែអាចចូលទៅកាន់ប្រព័ន្ធអេកូ Python ទាំងមូល និងឧបករណ៍ទាំងអស់ (ដូចជា pytest)។ នេះមានន័យថា យើងអាចបន្តប្រើកូដ Python ដែលត្រូវបានបកស្រាយកំឡុងពេលអភិវឌ្ឍ ដែលអនុញ្ញាតឱ្យយើងបន្តធ្វើការជាមួយនឹងគំរូរហ័សនៃការផ្លាស់ប្តូរកូដ និងសាកល្បងវា ជាជាងរង់ចាំកូដដើម្បីចងក្រង។ វាហាក់ដូចជាយើងកំពុងធ្វើការងារដ៏អស្ចារ្យមួយក្នុងការអង្គុយលើកៅអីពីរ ដូច្នេះដើម្បីនិយាយ ហើយយើងចូលចិត្តវា។

កម្មវិធីចងក្រងដែលយើងហៅថា mypyc (ចាប់តាំងពីវាប្រើ mypy ជាផ្នែកខាងមុខសម្រាប់ការវិភាគប្រភេទ) បានប្រែក្លាយជាគម្រោងជោគជ័យខ្លាំង។ សរុបមក យើងសម្រេចបានការបង្កើនល្បឿនប្រហែល 4x សម្រាប់ការរត់ mypy ញឹកញាប់ដោយមិនមានឃ្លាំងសម្ងាត់។ ការអភិវឌ្ឍន៍ស្នូលនៃគម្រោង mypyc បានយកក្រុមតូចមួយរបស់ Michael Sullivan, Ivan Levkivsky, Hugh Hahn និងខ្លួនខ្ញុំប្រហែល 4 ខែប្រតិទិន។ ចំនួនការងារនេះគឺតូចជាងអ្វីដែលត្រូវការដើម្បីសរសេរ mypy ឡើងវិញ ឧទាហរណ៍នៅក្នុង C++ ឬ Go ។ ហើយ​យើង​ត្រូវ​តែ​ធ្វើ​ការ​ផ្លាស់​ប្តូ​រ​ច្រើន​តិច​ជាង​ការ​ដែល​យើង​ត្រូវ​ធ្វើ​នៅ​ពេល​ដែល​យើង​ត្រូវ​ធ្វើ​ការ​សរសេរ​វា​ជា​ភាសា​ផ្សេង​ទៀត​។ យើងក៏សង្ឃឹមផងដែរថា យើងអាចនាំយក mypyc ដល់កម្រិតមួយដែលអ្នកសរសេរកម្មវិធី Dropbox ផ្សេងទៀតអាចប្រើវាដើម្បីចងក្រង និងបង្កើនល្បឿនកូដរបស់ពួកគេ។

ដើម្បីសម្រេចបាននូវកម្រិតនៃការអនុវត្តនេះ យើងត្រូវអនុវត្តដំណោះស្រាយវិស្វកម្មគួរឱ្យចាប់អារម្មណ៍មួយចំនួន។ ដូចនេះ កម្មវិធីចងក្រងអាចបង្កើនល្បឿនប្រតិបត្តិការជាច្រើនដោយប្រើការស្ថាបនា C ដែលមានល្បឿនលឿន និងកម្រិតទាប។ ឧទាហរណ៍ ការហៅមុខងារដែលបានចងក្រងត្រូវបានបកប្រែទៅជាការហៅមុខងារ C ។ ហើយការហៅបែបនេះគឺលឿនជាងការហៅមុខងារដែលបានបកស្រាយ។ ប្រតិបត្តិការមួយចំនួន ដូចជាការរកមើលវចនានុក្រម នៅតែពាក់ព័ន្ធនឹងការប្រើប្រាស់ការហៅ C-API ធម្មតាពី CPython ដែលលឿនជាងបន្តិចនៅពេលចងក្រង។ យើងអាចលុបបំបាត់បន្ទុកបន្ថែមលើប្រព័ន្ធដែលបង្កើតឡើងដោយការបកស្រាយ ប៉ុន្តែក្នុងករណីនេះបានផ្តល់ផលចំណេញតិចតួចប៉ុណ្ណោះនៅក្នុងលក្ខខណ្ឌនៃការអនុវត្ត។

ដើម្បីកំណត់អត្តសញ្ញាណប្រតិបត្តិការ "យឺត" ទូទៅបំផុត យើងបានអនុវត្តទម្រង់កូដ។ ប្រដាប់ដោយទិន្នន័យនេះ យើងបានព្យាយាមកែប្រែ mypyc ដើម្បីឱ្យវាបង្កើតកូដ C លឿនជាងមុនសម្រាប់ប្រតិបត្តិការបែបនេះ ឬសរសេរកូដ Python ដែលត្រូវគ្នាឡើងវិញដោយប្រើប្រតិបត្តិការលឿនជាងមុន (ហើយពេលខ្លះយើងមិនមានដំណោះស្រាយគ្រប់គ្រាន់សម្រាប់បញ្ហានោះ ឬបញ្ហាផ្សេងទៀតទេ) . ការសរសេរកូដ Python ឡើងវិញជាញឹកញាប់ជាដំណោះស្រាយងាយស្រួលជាងចំពោះបញ្ហាជាងការឱ្យអ្នកចងក្រងធ្វើការបំប្លែងដូចគ្នាដោយស្វ័យប្រវត្តិ។ ក្នុងរយៈពេលវែង យើងចង់ធ្វើឱ្យការផ្លាស់ប្តូរជាច្រើនទាំងនេះដោយស្វ័យប្រវត្តិ ប៉ុន្តែនៅពេលនោះ យើងបានផ្តោតលើការបង្កើនល្បឿន mypy ដោយមានការខិតខំប្រឹងប្រែងតិចតួចបំផុត។ ហើយក្នុងការឆ្ពោះទៅរកគោលដៅនេះ យើងបានកាត់ជ្រុងជាច្រើន។

នៅ​មាន​ជា​បន្ត​ទៀត…

អ្នកអានជាទីស្រឡាញ់! តើអ្នកចាប់អារម្មណ៍អ្វីខ្លះចំពោះគម្រោង mypy នៅពេលអ្នកដឹងពីអត្ថិភាពរបស់វា?

ប្រភព: www.habr.com