ہم آپ کی توجہ کے لیے مواد کے ترجمے کا تیسرا حصہ اس راستے کے بارے میں پیش کرتے ہیں جو ڈراپ باکس نے پائتھون کوڈ کے لیے ٹائپ چیکنگ سسٹم کو نافذ کرتے وقت اختیار کیا تھا۔
→ پچھلے حصے: и
ٹائپ شدہ کوڈ کی 4 ملین لائنوں تک پہنچنا
ایک اور بڑا چیلنج (اور اندرونی طور پر سروے کرنے والوں میں دوسری سب سے عام تشویش) ڈراپ باکس میں ٹائپ چیک کے ذریعے کور کردہ کوڈ کی مقدار میں اضافہ کرنا تھا۔ ہم نے اس مسئلے کو حل کرنے کے لیے کئی طریقے آزمائے ہیں، قدرتی طور پر ٹائپ شدہ کوڈ بیس کے سائز کو بڑھانے سے لے کر جامد اور متحرک خودکار قسم کے تخمینے پر mypy ٹیم کی کوششوں پر توجہ مرکوز کرنے تک۔ آخر میں، ایسا لگتا تھا کہ جیتنے کی کوئی آسان حکمت عملی نہیں تھی، لیکن ہم بہت سے طریقوں کو ملا کر تشریح شدہ کوڈ کے حجم میں تیزی سے ترقی حاصل کرنے میں کامیاب ہو گئے۔
نتیجے کے طور پر، ہماری سب سے بڑی Python ریپوزٹری (بیک اینڈ کوڈ کے ساتھ) میں تشریح شدہ کوڈ کی تقریباً 4 ملین لائنیں ہیں۔ جامد کوڈ ٹائپنگ پر کام تقریباً تین سالوں میں مکمل ہوا۔ Mypy اب مختلف قسم کے کوڈ کوریج رپورٹس کو سپورٹ کرتا ہے جو ٹائپنگ کی پیشرفت کو مانیٹر کرنا آسان بناتی ہے۔ خاص طور پر، ہم قسموں میں ابہام کے ساتھ کوڈ پر رپورٹس تیار کر سکتے ہیں، جیسے، مثال کے طور پر، کسی قسم کا واضح استعمال Any تشریحات میں جن کی تصدیق نہیں کی جاسکتی ہے، یا تیسری پارٹی کی لائبریریوں کو درآمد کرنے جیسی چیزوں کے ساتھ جن میں ٹائپ تشریحات نہیں ہیں۔ ڈراپ باکس میں ٹائپ چیکنگ کی درستگی کو بہتر بنانے کے منصوبے کے حصے کے طور پر، ہم نے مرکزی پائیتھون ریپوزٹری میں کچھ مشہور اوپن سورس لائبریریوں کے لیے ٹائپ ڈیفینیشنز (نام نہاد اسٹب فائلز) کو بہتر بنانے میں تعاون کیا۔ .
ہم نے ٹائپ سسٹم کی نئی خصوصیات کو نافذ کیا (اور بعد میں پی ای پی میں معیاری بنایا) جو کچھ مخصوص Python پیٹرن کے لیے زیادہ درست اقسام کی اجازت دیتے ہیں۔ اس کی ایک قابل ذکر مثال ہے۔ TypeDict، جو JSON جیسی لغات کے لیے اقسام فراہم کرتا ہے جن میں سٹرنگ کیز کا ایک مقررہ سیٹ ہوتا ہے، ہر ایک کی اپنی قسم کی قدر ہوتی ہے۔ ہم ٹائپ سسٹم کو بڑھاتے رہیں گے۔ ہمارا اگلا قدم ممکنہ طور پر Python کی عددی صلاحیتوں کے لیے سپورٹ کو بہتر بنانا ہے۔
تشریح شدہ کوڈ کی لائنوں کی تعداد: سرور
تشریح شدہ کوڈ کی لائنوں کی تعداد: کلائنٹ
تشریح شدہ کوڈ کی لائنوں کی کل تعداد
ڈراپ باکس میں تشریح شدہ کوڈ کی مقدار بڑھانے کے لیے ہم نے جو کام کیے ان کی اہم خصوصیات کا ایک جائزہ یہ ہے:
تشریح کی سختی۔ ہم نے آہستہ آہستہ نئے کوڈ کی تشریح کی سختی کے تقاضوں میں اضافہ کیا۔ ہم نے لنٹر ٹپس کے ساتھ شروعات کی جس میں ان فائلوں میں تشریحات شامل کرنے کا مشورہ دیا گیا جن میں پہلے سے کچھ تشریحات موجود تھیں۔ اب ہمیں نئی Python فائلوں اور زیادہ تر موجودہ فائلوں میں ٹائپ تشریحات کی ضرورت ہے۔
رپورٹیں ٹائپ کرنا۔ ہم ٹیموں کو ان کے کوڈ میں ٹائپنگ کی سطح پر ہفتہ وار رپورٹ بھیجتے ہیں اور مشورہ دیتے ہیں کہ پہلے کیا تشریح کی جانی چاہیے۔
mypy کی مقبولیت۔ ہم تقریبات میں mypy کے بارے میں بات کرتے ہیں اور قسم کی تشریحات کے ساتھ شروع کرنے میں مدد کرنے کے لیے ٹیموں سے بات کرتے ہیں۔
پولز ہم بڑے مسائل کی نشاندہی کرنے کے لیے وقتاً فوقتاً صارف سروے کرتے ہیں۔ ہم ان مسائل کو حل کرنے کے لیے کافی آگے جانے کے لیے تیار ہیں (یہاں تک کہ mypy کو تیز کرنے کے لیے ایک نئی زبان بھی تخلیق کریں!)۔
کارکردگی۔ ہم نے ڈیمون اور mypyc کا استعمال کرکے mypy کی کارکردگی کو بہت بہتر کیا ہے۔ یہ تشریح کے عمل کے دوران پیدا ہونے والی تکلیفوں کو ہموار کرنے کے لیے اور کوڈ کی بڑی مقدار کے ساتھ کام کرنے کے قابل ہونے کے لیے کیا گیا تھا۔
ایڈیٹرز کے ساتھ انضمام۔ ہم نے ایڈیٹرز میں mypy چلانے کی حمایت کرنے کے لیے ٹولز بنائے ہیں جو Dropbox پر مقبول ہیں۔ اس میں PyCharm، Vim اور VS Code شامل ہیں۔ اس نے کوڈ کی تشریح اور اس کی فعالیت کو جانچنے کے عمل کو بہت آسان بنا دیا۔ موجودہ کوڈ کی تشریح کرتے وقت اس قسم کی کارروائیاں عام ہیں۔
جامد تجزیہ۔ ہم نے جامد تجزیہ ٹولز کا استعمال کرتے ہوئے فنکشن کے دستخطوں کا اندازہ لگانے کے لیے ایک ٹول بنایا ہے۔ یہ ٹول صرف نسبتاً آسان حالات میں کام کر سکتا ہے، لیکن اس نے ہماری کوڈ ٹائپ کوریج کو زیادہ کوشش کے بغیر بڑھانے میں مدد کی۔
تھرڈ پارٹی لائبریریوں کے لیے سپورٹ۔ ہمارے بہت سے پروجیکٹ SQLAlchemy ٹول کٹ استعمال کرتے ہیں۔ یہ Python کی متحرک صلاحیتوں سے فائدہ اٹھاتا ہے کہ PEP 484 قسمیں براہ راست ماڈل کرنے سے قاصر ہیں۔ ہم نے PEP 561 کے مطابق متعلقہ سٹب فائل بنائی اور mypy کے لیے ایک پلگ ان لکھا ()، جو SQLAlchemy سپورٹ کو بہتر بناتا ہے۔
مشکلات کا سامنا کرنا پڑا
ٹائپ شدہ کوڈ کی 4 ملین لائنوں کا راستہ ہمارے لیے ہمیشہ آسان نہیں رہا۔ اس راستے میں ہم نے بہت سے گڑھوں کا سامنا کیا اور کئی غلطیاں کیں۔ یہ کچھ مسائل ہیں جن کا ہم نے سامنا کیا۔ ہم امید کرتے ہیں کہ ان کے بارے میں بتانے سے دوسروں کو اسی طرح کے مسائل سے بچنے میں مدد ملے گی۔
فائلیں غائب ہیں۔ ہم نے اپنا کام صرف تھوڑی سی فائلوں کو چیک کرکے شروع کیا۔ ان فائلوں میں شامل کسی بھی چیز کی جانچ نہیں کی گئی۔ فائلوں کو اسکیننگ لسٹ میں شامل کیا گیا جب ان میں پہلی تشریحات ظاہر ہوئیں۔ اگر تصدیق کے دائرہ سے باہر واقع کسی ماڈیول سے کچھ درآمد کیا گیا تھا، تو ہم اقدار کے ساتھ کام کرنے کے بارے میں بات کر رہے تھے جیسے Any، جن کا بالکل تجربہ نہیں کیا گیا تھا۔ اس کی وجہ سے ٹائپنگ کی درستگی کا خاصا نقصان ہوا، خاص طور پر ہجرت کے ابتدائی مراحل میں۔ اس نقطہ نظر نے اب تک حیرت انگیز طور پر اچھی طرح سے کام کیا ہے، حالانکہ ایک عام صورت حال یہ ہے کہ فائلوں کو جائزہ کے دائرہ کار میں شامل کرنے سے کوڈ بیس کے دیگر حصوں میں مسائل کا پتہ چلتا ہے۔ بدترین صورت میں، جب کوڈ کے دو الگ تھلگ علاقوں کو ملایا گیا، جس میں، ایک دوسرے سے آزادانہ طور پر، اقسام کو پہلے سے ہی چیک کیا گیا تھا، تو پتہ چلا کہ ان علاقوں کی اقسام ایک دوسرے سے مطابقت نہیں رکھتی تھیں۔ اس کی وجہ سے تشریحات میں بہت سی تبدیلیاں کرنے کی ضرورت پیش آئی۔ اب پیچھے مڑ کر دیکھتے ہیں، ہمیں احساس ہوتا ہے کہ ہمیں جلد ہی mypy کے ٹائپ چیکنگ ایریا میں بنیادی لائبریری ماڈیولز کو شامل کرنا چاہیے تھا۔ یہ ہمارے کام کو بہت زیادہ پیش قیاسی بنا دے گا۔
پرانے کوڈ کی تشریح کرنا۔ جب ہم نے شروع کیا تو ہمارے پاس موجود Python کوڈ کی تقریباً 4 ملین لائنیں تھیں۔ یہ واضح تھا کہ اس تمام کوڈ کی تشریح کرنا آسان کام نہیں تھا۔ ہم نے PyAnnotate کے نام سے ایک ٹول بنایا ہے جو ٹیسٹ کے دوران قسم کی معلومات جمع کر سکتا ہے اور جمع کی گئی معلومات کی بنیاد پر آپ کے کوڈ میں قسم کی تشریحات شامل کر سکتا ہے۔ تاہم، ہم نے اس ٹول کے خاص طور پر بڑے پیمانے پر اپنانے کا مشاہدہ نہیں کیا ہے۔ قسم کی معلومات جمع کرنا سست تھا، اور خود بخود پیدا ہونے والی تشریحات کو اکثر دستی ترامیم کی ضرورت پڑتی تھی۔ جب بھی ہم کوڈ کا جائزہ لیتے ہیں تو ہم نے اس ٹول کو خود بخود چلانے کے بارے میں سوچا، یا حقیقی نیٹ ورک کی درخواستوں کے کچھ چھوٹے حجم کا تجزیہ کرنے کی بنیاد پر قسم کی معلومات جمع کرنے کے بارے میں سوچا، لیکن ایسا نہ کرنے کا فیصلہ کیا کیونکہ دونوں میں سے کوئی بھی طریقہ بہت خطرناک تھا۔
نتیجے کے طور پر، یہ نوٹ کیا جا سکتا ہے کہ زیادہ تر کوڈ کو اس کے مالکان نے دستی طور پر بیان کیا تھا۔ اس عمل کی صحیح سمت میں رہنمائی کرنے کے لیے، ہم خاص طور پر اہم ماڈیولز اور فنکشنز کے بارے میں رپورٹس تیار کرتے ہیں جن پر تشریح کرنے کی ضرورت ہے۔ مثال کے طور پر، لائبریری ماڈیول کے لیے ٹائپ تشریحات فراہم کرنا ضروری ہے جو سینکڑوں جگہوں پر استعمال ہوتا ہے۔ لیکن ایک پرانی سروس جس کو ایک نئی سے تبدیل کیا جا رہا ہے اب تشریح کرنے کے لیے اتنا اہم نہیں ہے۔ ہم وراثت کوڈ کے لیے قسم کی تشریحات تیار کرنے کے لیے جامد تجزیہ استعمال کرنے کا بھی تجربہ کر رہے ہیں۔
سائیکلک درآمدات۔ اوپر، میں نے سائیکلک درآمدات ("انحصار الجھاؤ") کے بارے میں بات کی، جس کے وجود نے مائی پی کو تیز کرنا مشکل بنا دیا۔ ہمیں mypy کو ہر قسم کے محاوروں کی حمایت کرنے کے لیے بھی سخت محنت کرنی پڑی جو ان چکراتی درآمدات کی وجہ سے ہیں۔ ہم نے حال ہی میں ایک بڑا سسٹم ری ڈیزائن پروجیکٹ مکمل کیا ہے جس نے سرکلر امپورٹس کے حوالے سے mypy کے زیادہ تر مسائل کو حل کر دیا ہے۔ یہ مسائل دراصل پراجیکٹ کے ابتدائی دنوں سے پیدا ہوئے ہیں، الور سے واپس آنے والی تعلیمی زبان جس پر mypy پروجیکٹ کی اصل توجہ مرکوز تھی۔ الور نحو سائیکلک امپورٹ کمانڈز کے ساتھ مسائل کو حل کرنا آسان بناتا ہے۔ جدید mypy کو اس کے پہلے، سادہ ذہن کے نفاذ سے کچھ حدود وراثت میں ملی ہیں (جو الور کے لیے بہت موزوں تھی)۔ Python سرکلر درآمدات کے ساتھ کام کرنا مشکل بناتا ہے، بنیادی طور پر اس لیے کہ تاثرات مبہم ہیں۔ مثال کے طور پر، ایک اسائنمنٹ آپریشن دراصل ایک قسم کے عرف کی وضاحت کر سکتا ہے۔ Mypy ہمیشہ اس طرح کی چیزوں کا پتہ لگانے کے قابل نہیں ہوتا ہے جب تک کہ زیادہ تر امپورٹ لوپ پر کارروائی نہ ہو جائے۔ الور میں ایسے ابہام نہیں تھے۔ نظام کی نشوونما کے ابتدائی مراحل میں کیے گئے ناقص فیصلے کئی سالوں بعد پروگرامر کے لیے ایک ناخوشگوار حیرت پیش کر سکتے ہیں۔
نتائج: کوڈ کی 5 ملین لائنوں اور نئے افق کا راستہ
mypy پروجیکٹ نے ایک لمبا فاصلہ طے کیا ہے - ابتدائی پروٹو ٹائپ سے لے کر ایک ایسے سسٹم تک جو پروڈکشن کوڈ کی اقسام کی 4 ملین لائنوں کو کنٹرول کرتا ہے۔ جیسے جیسے mypy تیار ہوا، ازگر کے قسم کے اشارے معیاری ہو گئے۔ ان دنوں، پائتھون کوڈ ٹائپ کرنے کے ارد گرد ایک طاقتور ماحولیاتی نظام تیار ہوا ہے۔ اس میں لائبریری سپورٹ کے لیے ایک جگہ ہے، یہ IDEs اور ایڈیٹرز کے لیے معاون ٹولز پر مشتمل ہے، اس میں کئی قسم کے کنٹرول سسٹم ہیں، جن میں سے ہر ایک کے اپنے فائدے اور نقصانات ہیں۔
اگرچہ ڈراپ باکس میں ٹائپ چیکنگ پہلے ہی دی گئی ہے، مجھے یقین ہے کہ ہم ابھی بھی ازگر کوڈ ٹائپ کرنے کے ابتدائی دنوں میں ہیں۔ میرے خیال میں ٹائپ چیکنگ ٹیکنالوجیز تیار اور بہتر ہوتی رہیں گی۔
اگر آپ نے پہلے سے ہی اپنے بڑے پیمانے پر Python پروجیکٹ میں ٹائپ چیکنگ کا استعمال نہیں کیا ہے، تو جان لیں کہ اب جامد ٹائپنگ کی طرف بڑھنا شروع کرنے کا بہت اچھا وقت ہے۔ میں نے ان لوگوں سے بات کی ہے جنہوں نے اسی طرح کی تبدیلی کی ہے۔ ان میں سے کسی کو بھی افسوس نہیں ہوا۔ ٹائپ چیکنگ Python کو ایک ایسی زبان بناتی ہے جو "باقاعدہ ازگر" کے مقابلے میں بڑے پروجیکٹس کو تیار کرنے کے لیے زیادہ موزوں ہے۔
پیارے قارئین! کیا آپ اپنے Python پروجیکٹس میں ٹائپ چیکنگ کا استعمال کرتے ہیں؟
ماخذ: www.habr.com