نن ورځ موږ د موادو د ژباړې دویمه برخه خپروو چې څنګه ډراپ باکس د پیتون کوډ څو ملیون لینونو لپاره ډول کنټرول تنظیموي.
→
د رسمي ډول ملاتړ (PEP 484)
موږ د هیک اونۍ 2014 په جریان کې په ډراپ باکس کې د mypy سره زموږ لومړۍ جدي تجربې ترسره کړې. د هیک اونۍ یوه اونۍ پیښه ده چې د ډراپ باکس لخوا کوربه توب کیږي. د دې وخت په جریان کې، کارمندان کولی شي په هر هغه څه کار وکړي چې دوی یې غواړي! د ډراپ باکس ځینې خورا مشهور ټیکنالوژي پروژې د دې په څیر پیښو کې پیل شوې. د دې تجربې په پایله کې، موږ دې نتیجې ته ورسیدو چې مایپی امید لرونکی ښکاري، که څه هم پروژه لاهم د پراخه کارونې لپاره چمتو نه ده.
په هغه وخت کې، د Python ډوله اشارو سیسټمونو معیاري کولو نظر په هوا کې و. لکه څنګه چې ما وویل، د Python 3.0 راهیسې دا ممکنه وه چې د دندو لپاره د ډول تشریحات وکاروئ، مګر دا یوازې خپل سري څرګندونې وې، پرته له تعریف شوي نحو او سیمانټیک. د پروګرام اجرا کولو په جریان کې، دا تشریحات، د ډیری برخې لپاره، په ساده ډول له پامه غورځول شوي. د هیک اونۍ وروسته، موږ د سیمانټیک معیاري کولو کار پیل کړ. دا کار د ظهور لامل شو (Guido van Rossum، Łukasz Langa او ما په دې سند کې همکاري وکړه).
زموږ انګیزه له دوو اړخونو لیدل کیدی شي. لومړی، موږ هیله درلوده چې د پایتون ټول ایکوسیستم کولی شي د ډول اشارو کارولو لپاره یو عام چلند غوره کړي (یو اصطلاح چې په پایتون کې د "ډول تشریحاتو" مساوي په توګه کارول کیږي). دا، د احتمالي خطرونو په پام کې نیولو سره، دا به د ډیرو متقابلو متقابلو لارو چارو کارولو څخه غوره وي. دوهم، موږ غوښتل چې د پایتون ټولنې ډیری غړو سره د ډول تشریح میکانیزمونو په اړه په ښکاره ډول بحث وکړو. دا هیله تر یوې اندازې د دې حقیقت له مخې ټاکل شوې وه چې موږ نه غواړو د Python پروګرام کونکو پراخو خلکو په سترګو کې د ژبې له بنسټیزو نظرونو څخه د "مرتد" په څیر وګورو. دا په متحرک ډول ټایپ شوې ژبه ده چې د "دک ټایپ کولو" په نوم پیژندل کیږي. په ټولنه کې، په لومړي سر کې، د جامد ټایپ کولو مفکورې په اړه یو څه شکمن چلند نشي کولی مرسته وکړي مګر رامنځ ته شي. مګر دا احساس په پای کې وروسته له هغه ورک شو چې روښانه شوه چې جامد ټایپ کول به لازمي نه وي (او وروسته له دې چې خلک پوه شول چې دا واقعیا ګټور و).
د نښې نحو ډول چې په نهایت کې منل شوی و د هغه څه سره ورته و چې مایپي په هغه وخت کې ملاتړ کاوه. PEP 484 په 3.5 کې د Python 2015 سره خپور شو. Python نور په متحرک ډول ټایپ شوې ژبه نه وه. زه غواړم د دې پیښې په اړه د Python تاریخ کې د پام وړ مرحلې په توګه فکر وکړم.
د مهاجرت پیل
د 2015 په پای کې، ډراپ باکس په مایپي کې کار کولو لپاره د دریو کسانو ټیم جوړ کړ. په دوی کې ګیډو وان روسم، ګریګ قیمت او ډیویډ فشر شامل وو. له هغه وخته، وضعیت خورا چټک پرمختګ پیل کړ. د Mypy د ودې لپاره لومړی خنډ فعالیت و. لکه څنګه چې ما پورته اشاره وکړه، د پروژې په لومړیو ورځو کې ما په C کې د mypy تطبیق د ژباړلو په اړه فکر کاوه، مګر دا نظر د اوس لپاره له لیست څخه تیر شو. موږ د CPython ژباړونکي په کارولو سره د سیسټم چلولو سره پاتې یو، کوم چې د mypy په څیر وسیلو لپاره کافي ګړندی ندی. (د PyPy پروژه، د JIT کمپیلر سره د پایتون بدیل پلي کول، هم زموږ سره مرسته نه ده کړې.)
خوشبختانه، ځینې الګوریتمیک پرمختګونه دلته زموږ مرستې ته راغلي دي. لومړی پیاوړی "سرعت کونکی" د زیاتیدونکي چک پلي کول وو. د دې پرمختګ ترشا مفکوره ساده وه: که چیرې د مایپي د تیرې دورې راهیسې د ماډل ټول انحصارونه نه وي بدل شوي، نو موږ کولی شو د انحصاراتو سره کار کولو پرمهال د تیرې دورې په جریان کې زیرمه شوي ډاټا وکاروو. موږ یوازې د بدل شوي فایلونو او په هغه فایلونو کې چې په دوی پورې اړه لري د ډول چیک کولو ته اړتیا درلوده. Mypy حتی یو څه نور هم لاړ: که چیرې د ماډل بهرنۍ انٹرفیس بدل نه شي، مایپي داسې انګیرله چې نور ماډلونه چې دا ماډل یې وارد کړي بیا چک کولو ته اړتیا نلري.
زیاتیدونکي چک کول زموږ سره ډیره مرسته کړې کله چې د موجوده کوډ لوی مقدار تشریح کول. ټکی دا دی چې پدې پروسه کې معمولا د mypy ډیری تکراري منډې شاملې وي ځکه چې تشریحات په تدریجي ډول کوډ ته اضافه کیږي او ورو ورو ښه کیږي. د mypy لومړی چل لاهم خورا ورو و ځکه چې دا د چک کولو لپاره ډیری انحصار درلود. بیا، د وضعیت ښه کولو لپاره، موږ د لیرې کیچ کولو میکانیزم پلي کړ. که mypy معلومه کړي چې سیمه ایز کیچ ممکن د نیټې څخه تیر وي، دا د مرکزي ذخیره څخه د ټول کوډبیس لپاره د اوسني کیچ سنیپ شاټ ډاونلوډ کوي. دا بیا د دې سنیپ شاټ په کارولو سره زیاتیدونکي چک ترسره کوي. دا موږ د مایپي د فعالیت زیاتوالي په لور یو بل لوی ګام اخیستی دی.
دا په ډراپ باکس کې د ډول چیک کولو ګړندۍ او طبیعي اختیار کولو دوره وه. د 2016 په پای کې، موږ دمخه د پیتون کوډ نږدې 420000 لینونه د ډول تشریحاتو سره درلودل. ډیری کاروونکي د ډول چک کولو په اړه لیواله وو. ډیر او ډیر پرمختیایی ټیمونه د Dropbox mypy کاروي.
بیا هرڅه ښه ښکاریده، مګر موږ لاهم ډیر څه درلودل. موږ د دوراني داخلي کاروونکو سروې پیل کړې ترڅو د پروژې ستونزې ساحې وپیژنو او پوه شو چې کوم مسلې باید لومړی حل شي (دا عمل لاهم په شرکت کې کارول کیږي). تر ټولو مهم، لکه څنګه چې څرګنده شوه، دوه دندې وې. لومړی، موږ د کوډ نور ډول پوښښ ته اړتیا درلوده، دوهم، موږ د چټک کار کولو لپاره مای پی ته اړتیا درلوده. دا په بشپړه توګه روښانه وه چې زموږ د mypy د ګړندي کولو او د شرکت په پروژو کې د پلي کولو کار لاهم بشپړ نه و. موږ، د دې دوو دندو په اهمیت پوره پوهیږو، د حل کولو په اړه یې ترتیب کوو.
ډیر تولید!
زیاتیدونکي چکونو mypy ګړندی کړی ، مګر وسیله لاهم ګړندۍ نه وه. ډیری زیاتیدونکي چک شاوخوا یوه دقیقه دوام وکړ. د دې لامل د سایکلیکل واردات و. دا به شاید هرڅوک حیران نه کړي چې په پایتون کې لیکل شوي لوی کوډبیسونو سره کار کړی. موږ د سلګونو ماډلونو سیټونه درلودل، چې هر یو یې په غیر مستقیم ډول نور ټول وارد کړل. که چیرې په وارداتي لوپ کې کومه فایل بدل شوی وي ، نو مای پی باید په هغه لوپ کې ټولې فایلونه پروسس کړي ، او ډیری وختونه کوم ماډلونه چې له دې لوپ څخه ماډلونه وارد کړي. یو ورته دوره د بدنام "انحصار ټیک" و چې په ډراپ باکس کې د ډیری ستونزو لامل شوی. یوځل چې دا جوړښت څو سوه ماډلونه درلودل، پداسې حال کې چې دا وارد شوي، په مستقیم یا غیر مستقیم ډول، ډیری ازموینې، دا د تولید کوډ کې هم کارول کیده.
موږ د سرکلر انحصارونو د "بې برخې کولو" امکان په پام کې نیولی، مګر موږ د دې کولو لپاره سرچینې نه درلودې. دلته ډیر کوډ و چې موږ ورسره اشنا نه وو. د پایلې په توګه، موږ د بدیل طریقې سره مخ شو. موږ پریکړه وکړه چې مایپي ژر تر ژره کار وکړي حتی د "انحصار تنګو" شتون کې. موږ دا هدف د mypy ډیمون په کارولو سره ترلاسه کړ. ډیمون د سرور پروسه ده چې دوه په زړه پوري وړتیاوې پلي کوي. لومړی، دا په حافظه کې د ټول کوډبیس په اړه معلومات ذخیره کوي. دا پدې مانا ده چې هرکله چې تاسو mypy چلوئ، تاسو اړتیا نلرئ د زرګونو وارد شوي انحصارونو پورې اړوند زیرمه شوي ډاټا بار کړئ. دوهم، هغه په دقت سره، د کوچنیو ساختماني واحدونو په کچه، د دندو او نورو ادارو ترمنځ انحصار تحلیلوي. د مثال په توګه، که فعالیت foo فنکشن غږوي bar، بیا یو انحصار شتون لري foo от bar. کله چې فایل بدل شي، ډیمون لومړی، په انزوا کې، یوازې بدل شوی فایل پروسس کوي. دا بیا پدې فایل کې د بهرني لید بدلونونو ته ګوري ، لکه د فعالیت لاسلیکونه بدل شوي. ډیمون یوازې د وارداتو په اړه مفصل معلومات کاروي ترڅو هغه افعال دوه ځله چیک کړي چې واقعیا بدل شوي فنکشن کاروي. عموما، د دې طریقې سره، تاسو باید ډیر لږ فعالیتونه وګورئ.
د دې ټولو پلي کول اسانه ندي، ځکه چې د اصلي مایپي تطبیق په یو وخت کې د یوې فایل پروسس کولو باندې خورا تمرکز درلود. موږ باید د ډیری سرحدونو حالتونو سره معامله وکړو، چې د هغې پیښې په هغه قضیو کې چې په کوډ کې یو څه بدلون موندلی تکرار چکونو ته اړتیا لري. د مثال په توګه، دا پیښیږي کله چې یو ټولګي د نوي بیس ټولګي ګمارل کیږي. یوځل چې موږ هغه څه ترسره کړل چې موږ یې غوښتل ، موږ وکولی شو د ډیری زیاتیدونکي چیکونو اجرا کولو وخت یوازې څو ثانیو ته راکم کړو. دا زموږ لپاره د یوې لویې بریا په څیر بریښي.
حتی ډیر تولید!
د ریموټ کیشینګ سره یوځای چې ما پورته بحث وکړ ، مای پی ډیمون نږدې په بشپړ ډول هغه ستونزې حل کړې چې رامینځته کیږي کله چې یو پروګرامر په مکرر ډول ډول چیک کول پرمخ وړي ، په لږ شمیر فایلونو کې بدلونونه رامینځته کوي. په هرصورت، د لږترلږه مناسب کارونې قضیه کې د سیسټم فعالیت لاهم د مطلوب څخه لرې و. د mypy پاک پیل کولی شي 15 دقیقې وخت ونیسي. او دا د هغه څه څخه ډیر وو چې موږ به یې خوښ وو. هره اونۍ وضعیت خراب شو ځکه چې برنامه کونکي نوي کوډ لیکلو ته دوام ورکوي او موجوده کوډونو ته توضیحات اضافه کوي. زموږ کاروونکي لاهم د لا ډیر فعالیت لپاره وږي وو، مګر موږ خوشحاله یو چې دوی نیمایي ته ورسیدو.
موږ پریکړه وکړه چې د مایپي په اړه یو له پخوانیو نظرونو څخه بیرته راستانه شو. د مثال په توګه ، د Python کوډ په C کوډ بدلولو لپاره. د سایتون سره تجربه کول (یو سیسټم چې تاسو ته اجازه درکوي په Python کې لیکل شوي کوډ په C کوډ کې وژباړئ) موږ ته هیڅ ښکاره سرعت ندی راکړی ، نو موږ پریکړه وکړه چې د خپل کمپیلر لیکلو نظر بیا راژوندي کړو. څرنګه چې د mypy کوډبیس (په Python کې لیکل شوی) لا دمخه ټول اړین ډول تشریحات لري، موږ فکر کاوه چې دا به د ارزښت وړ وي چې د سیسټم چټکولو لپاره د دې تشریحاتو کارولو هڅه وکړو. ما په چټکۍ سره د دې نظر آزموینې لپاره یو پروټوټایپ جوړ کړ. دا په مختلف مایکرو بنچمارکونو کې په فعالیت کې له 10 څخه ډیر زیاتوالی ښیې. زموږ نظر دا و چې د Python ماډلونه د Cython په کارولو سره C ماډلونو ته تالیف کړي، او د ټایپ تشریحات د رن ټایم ټایپ چیکونو ته واړوي (معمولا د ټایپ تشریحات د چلولو وخت کې له پامه غورځول کیږي او یوازې د ډول چیک کولو سیسټمونو لخوا کارول کیږي). موږ واقعیا پلان درلود چې د مایپي پلي کول له Python څخه په داسې ژبه کې وژباړو چې په سټاټیک ډول ټایپ کولو لپاره ډیزاین شوی و ، دا به د Python په څیر (او د ډیری برخې لپاره کار) ښکاري. (دا ډول د کراس ژبې مهاجرت د مایپي پروژې په دود بدل شوی دی. د مایپي اصلي تطبیق په الور کې لیکل شوی و، بیا د جاوا او پایتون ترکیبي هایبرډ شتون درلود).
د CPython توسیع API باندې تمرکز د پروژې مدیریت وړتیا له لاسه ورکولو لپاره کلیدي وه. موږ د مجازی ماشین یا کوم کتابتون پلي کولو ته اړتیا نه درلوده چې مای پی ورته اړتیا لري. سربیره پردې ، موږ به لاهم د پایتون ټول ایکوسیستم او ټولو وسیلو ته لاسرسی ولرو (لکه pytest). د دې معنی دا وه چې موږ کولی شو د پراختیا په جریان کې تشریح شوي Python کوډ کارولو ته دوام ورکړو ، موږ ته اجازه راکوي چې د کوډ تالیف کولو ته انتظار کولو پرځای د کوډ بدلونونو او ازموینې خورا ګړندۍ نمونې سره کار کولو ته دوام ورکړو. داسې ښکاریده چې موږ په دوو چوکیو ناست یو ښه کار کوو، نو د خبرو کولو لپاره، او موږ یې خوښوو.
تالیف کونکی، کوم چې موږ یې مایپیک وایو (ځکه چې دا د ډولونو تحلیل کولو لپاره د مخکښې پای په توګه mypy کاروي)، یوه خورا بریالۍ پروژه وه. په ټولیز ډول، موږ د کیچ کولو پرته د مکرر mypy منډو لپاره نږدې 4x سرعت ترلاسه کړ. د mypyc پروژې د اصلي پراختیا لپاره د مایکل سلیوان، ایوان لیوکیفسکي، هیګ هان، او ځان د 4 تقویم میاشتو یوه کوچنۍ ډله ونیوله. د کار دا مقدار د هغه څه په پرتله خورا کوچنی و چې د mypy بیا لیکلو لپاره به ورته اړتیا وه ، د مثال په توګه په C++ یا Go کې. او موږ باید په پروژه کې د هغه په پرتله ډیر لږ بدلونونه رامینځته کړو چې موږ به یې په بله ژبه کې د بیا لیکلو پرمهال رامینځته کړي. موږ دا هیله هم درلوده چې موږ وکولی شو mypyc داسې کچې ته راوړو چې د ډراپ باکس نور پروګرام کونکي وکولی شي د دوی کوډ تالیف او ګړندي کولو لپاره وکاروي.
د دې کچې فعالیت ترلاسه کولو لپاره ، موږ باید ځینې په زړه پوري انجینري حلونه پلي کړو. په دې توګه، کمپیلر کولی شي د ګړندي، ټیټې کچې C ساختمانونو په کارولو سره ډیری عملیات ګړندي کړي، د بیلګې په توګه، یو کمپل شوی فنکشن کال د C فنکشن کال ته ژباړل کیږي. او دا ډول زنګ د تشریح شوي فنکشن زنګ وهلو په پرتله خورا ګړندی دی. ځینې عملیات، لکه د لغت لټون کول، لاهم د CPython څخه د منظم C-API کالونو کارول شامل دي، کوم چې یوازې د تالیف کولو په وخت کې لږ څه چټک وو. موږ وکولی شو د تفسیر لخوا رامینځته شوي سیسټم کې اضافي بار له مینځه یوسو ، مګر پدې حالت کې د فعالیت په شرایطو کې یوازې لږه ګټه ورکړل شوه.
د ډیری عام "ورو" عملیاتو پیژندلو لپاره، موږ د کوډ پروفایل کول ترسره کړل. د دې معلوماتو سره سمبال شوي، موږ هڅه وکړه چې یا mypyc ټیک کړو ترڅو دا د ورته عملیاتو لپاره ګړندی C کوډ رامینځته کړي ، یا د ګړندي عملیاتو په کارولو سره اړوند Python کوډ بیا ولیکي (او ځینې وختونه موږ د دې یا بلې ستونزې لپاره ساده کافي حل نه درلود) . د Python کوډ بیا لیکل اکثرا د ستونزې لپاره اسانه حل و چې د کمپیلر په اتوماتيک ډول ورته بدلون ترسره کړي. په اوږد مهال کې، موږ غوښتل چې ډیری دا بدلونونه اتومات کړو، مګر په هغه وخت کې موږ د لږترلږه هڅو سره د mypy په چټکولو تمرکز درلود. او د دې هدف په لور په حرکت کې، موږ څو کونجونه پرې کړل.
نور بیا…
ګرانو لوستونکو! کله چې تاسو د دې د شتون په اړه زده کړل د mypy پروژې ستاسو تاثیرات څه وو؟
سرچینه: www.habr.com