Python کوڈ کی 4 ملین لائنوں کو ٹائپ چیک کرنے کا راستہ۔ حصہ 1

آج ہم آپ کی توجہ اس مواد کے ترجمے کا پہلا حصہ لاتے ہیں کہ ڈراپ باکس پائتھون کوڈ کے ٹائپ کنٹرول سے کیسے نمٹتا ہے۔

Python کوڈ کی 4 ملین لائنوں کو ٹائپ چیک کرنے کا راستہ۔ حصہ 1

ڈراپ باکس ازگر میں بہت کچھ لکھتا ہے۔ یہ ایک ایسی زبان ہے جسے ہم بیک اینڈ سروسز اور ڈیسک ٹاپ کلائنٹ ایپلی کیشنز دونوں کے لیے بہت وسیع پیمانے پر استعمال کرتے ہیں۔ ہم Go، TypeScript اور Rust بھی بہت استعمال کرتے ہیں، لیکن Python ہماری بنیادی زبان ہے۔ ہمارے پیمانے پر غور کرتے ہوئے، اور ہم Python کوڈ کی لاکھوں لائنوں کے بارے میں بات کر رہے ہیں، یہ پتہ چلا کہ اس طرح کے کوڈ کی متحرک ٹائپنگ نے غیر ضروری طور پر اس کی سمجھ کو پیچیدہ کر دیا اور محنت کی پیداواری صلاحیت کو شدید متاثر کرنا شروع کر دیا۔ اس مسئلے کو کم کرنے کے لیے، ہم نے mypy کا استعمال کرتے ہوئے اپنے کوڈ کو بتدریج جامد قسم کی جانچ میں منتقل کرنا شروع کر دیا ہے۔ یہ شاید ازگر کے لیے سب سے زیادہ مقبول اسٹینڈ لون ٹائپ چیکنگ سسٹم ہے۔ Mypy ایک اوپن سورس پروجیکٹ ہے، اس کے مرکزی ڈویلپر ڈراپ باکس میں کام کرتے ہیں۔

ڈراپ باکس پہلی کمپنیوں میں سے ایک تھی جس نے اس پیمانے پر پائتھون کوڈ میں جامد قسم کی جانچ کو لاگو کیا۔ Mypy ان دنوں ہزاروں منصوبوں میں استعمال ہوتا ہے۔ یہ آلہ ان گنت بار، جیسا کہ وہ کہتے ہیں، "جنگ میں آزمایا گیا"۔ جہاں ہم ہیں وہاں تک پہنچنے کے لیے ہم نے ایک طویل سفر طے کیا ہے۔ راستے میں بہت سے ناکام کام اور ناکام تجربات ہوئے۔ یہ پوسٹ Python میں جامد قسم کی جانچ پڑتال کی تاریخ کا احاطہ کرتی ہے، میرے تحقیقی منصوبے کے ایک حصے کے طور پر اس کے پتھریلے آغاز سے لے کر آج تک، جب ٹائپ چیکنگ اور ٹائپ اشارہ Python میں لکھنے والے لاتعداد ڈویلپرز کے لیے عام ہو چکے ہیں۔ یہ میکانزم اب بہت سے ٹولز جیسے کہ IDEs اور کوڈ تجزیہ کاروں کے ذریعے تعاون یافتہ ہیں۔

دوسرا حصہ پڑھیں

ٹائپ چیکنگ کیوں ضروری ہے؟

اگر آپ نے کبھی متحرک طور پر ٹائپ شدہ Python استعمال کیا ہے، تو آپ کو کچھ الجھن ہو سکتی ہے کہ حال ہی میں جامد ٹائپنگ اور mypy کے ارد گرد اتنا ہنگامہ کیوں ہوا ہے۔ یا ہوسکتا ہے کہ آپ Python کو اس کی متحرک ٹائپنگ کی وجہ سے بالکل پسند کرتے ہوں، اور جو کچھ ہو رہا ہے وہ آپ کو پریشان کرتا ہے۔ جامد ٹائپنگ کی قدر کی کلید حلوں کا پیمانہ ہے: آپ کا پروجیکٹ جتنا بڑا ہوگا، اتنا ہی زیادہ آپ جامد ٹائپنگ کی طرف جھکاؤ گے، اور آخر میں، آپ کو واقعی اس کی ضرورت ہوگی۔

فرض کریں کہ ایک خاص پروجیکٹ دسیوں ہزار لائنوں کے سائز تک پہنچ گیا ہے، اور یہ پتہ چلا کہ کئی پروگرامرز اس پر کام کر رہے ہیں۔ اسی طرح کے ایک پروجیکٹ کو دیکھتے ہوئے، ہمارے تجربے کی بنیاد پر، ہم کہہ سکتے ہیں کہ اس کے کوڈ کو سمجھنا ڈویلپرز کو پیداواری رکھنے کی کلید ہوگی۔ ٹائپ تشریحات کے بغیر، یہ جاننا مشکل ہو سکتا ہے، مثال کے طور پر، فنکشن کو کون سے آرگیومینٹ پاس کرنے ہیں، یا فنکشن کس قسم کی واپس آ سکتا ہے۔ یہاں عام سوالات ہیں جن کا جواب دینا اکثر ٹائپ تشریحات کا استعمال کیے بغیر مشکل ہوتا ہے۔

  • کیا یہ فنکشن واپس آ سکتا ہے۔ None?
  • یہ دلیل کیا ہونی چاہیے؟ items?
  • وصف کی قسم کیا ہے؟ id: int کیا یہ ہے، str، یا شاید کچھ حسب ضرورت قسم؟
  • کیا یہ دلیل ایک فہرست ہونی چاہئے؟ کیا اس میں ایک ٹیپل منتقل کرنا ممکن ہے؟

اگر آپ درج ذیل قسم کے تشریح شدہ کوڈ کے ٹکڑوں کو دیکھیں اور اسی طرح کے سوالات کے جوابات دینے کی کوشش کریں تو پتہ چلتا ہے کہ یہ سب سے آسان کام ہے:

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

  • read_metadata واپس نہیں آتا Noneچونکہ واپسی کی قسم نہیں ہے۔ Optional[…].
  • دلیل items لائنوں کا ایک سلسلہ ہے۔ اسے تصادفی طور پر نہیں دہرایا جا سکتا۔
  • وصف id بائٹس کی ایک تار ہے۔

ایک مثالی دنیا میں، کوئی توقع کرے گا کہ ایسی تمام باریکیوں کو بلٹ ان دستاویزات (ڈاکسٹرنگ) میں بیان کیا جائے گا۔ لیکن تجربہ اس حقیقت کی بہت ساری مثالیں دیتا ہے کہ اس طرح کی دستاویزات اکثر اس کوڈ میں نہیں دیکھی جاتی ہیں جس کے ساتھ آپ کو کام کرنا ہے۔ یہاں تک کہ اگر اس طرح کی دستاویزات کوڈ میں موجود ہیں، کوئی بھی اس کی مکمل درستگی پر اعتماد نہیں کرسکتا۔ یہ دستاویزات مبہم، غلط اور غلط فہمیوں کے لیے کھلی ہوسکتی ہیں۔ بڑی ٹیموں یا بڑے منصوبوں میں، یہ مسئلہ انتہائی شدید ہو سکتا ہے۔

جب کہ Python منصوبوں کے ابتدائی یا درمیانی مراحل میں سبقت لے جاتا ہے، بعض مواقع پر کامیاب پروجیکٹس اور کمپنیاں جو Python استعمال کرتی ہیں ان کو اہم سوال کا سامنا کرنا پڑ سکتا ہے: "کیا ہمیں ہر چیز کو مستحکم طور پر ٹائپ شدہ زبان میں لکھنا چاہیے؟"۔

ٹائپ چیکنگ سسٹم جیسے mypy ڈویلپر کو اقسام کو بیان کرنے کے لیے ایک رسمی زبان فراہم کرکے، اور اس قسم کے اعلانات پروگرام کے نفاذ سے میل کھا کر (اور اختیاری طور پر، ان کے وجود کی جانچ کرکے) مذکورہ مسئلہ کو حل کرتے ہیں۔ عام طور پر، ہم کہہ سکتے ہیں کہ یہ سسٹم ہمارے اختیار میں کچھ رکھتے ہیں جیسا کہ احتیاط سے چیک شدہ دستاویزات۔

اس طرح کے نظام کے استعمال کے دیگر فوائد ہیں، اور وہ پہلے سے ہی مکمل طور پر غیر معمولی ہیں:

  • ٹائپ چیکنگ سسٹم کچھ چھوٹی (اور اتنی چھوٹی نہیں) غلطیوں کا پتہ لگا سکتا ہے۔ ایک عام مثال یہ ہے کہ جب وہ کسی قدر پر کارروائی کرنا بھول جاتے ہیں۔ None یا کوئی اور خاص شرط؟
  • کوڈ ری فیکٹرنگ کو بہت آسان بنایا گیا ہے کیونکہ ٹائپ چیکنگ سسٹم اکثر اس بارے میں بہت درست ہوتا ہے کہ کوڈ کو تبدیل کرنے کی ضرورت ہے۔ ایک ہی وقت میں، ہمیں ٹیسٹ کے ساتھ 100% کوڈ کوریج کی امید کرنے کی ضرورت نہیں ہے، جو کہ کسی بھی صورت میں، عام طور پر ممکن نہیں ہے۔ ہمیں مسئلے کی وجہ معلوم کرنے کے لیے اسٹیک ٹریس کی گہرائی میں جانے کی ضرورت نہیں ہے۔
  • یہاں تک کہ بڑے پروجیکٹس پر بھی، mypy اکثر سیکنڈ کے ایک حصے میں مکمل قسم کی جانچ کر سکتا ہے۔ اور ٹیسٹوں پر عمل درآمد میں عام طور پر دسیوں سیکنڈ یا اس سے بھی منٹ لگتے ہیں۔ ٹائپ چیکنگ سسٹم پروگرامر کو فوری فیڈ بیک دیتا ہے اور اسے اپنا کام تیزی سے کرنے کی اجازت دیتا ہے۔ اسے یونٹ ٹیسٹوں کو برقرار رکھنے کے لیے اب نازک اور مشکل لکھنے کی ضرورت نہیں ہے جو حقیقی اداروں کو محض کوڈ ٹیسٹ کے نتائج تیزی سے حاصل کرنے کے لیے ماکس اور پیچ سے بدل دیتے ہیں۔

IDEs اور ایڈیٹرز جیسے PyCharm یا Visual Studio Code ڈویلپرز کو کوڈ کی تکمیل، غلطی کو نمایاں کرنے، اور عام طور پر استعمال ہونے والی زبان کی تعمیرات کے لیے معاونت فراہم کرنے کے لیے ٹائپ تشریحات کی طاقت کا استعمال کرتے ہیں۔ اور یہ ٹائپنگ کے چند فائدے ہیں۔ کچھ پروگرامرز کے لیے، یہ سب ٹائپنگ کے حق میں بنیادی دلیل ہے۔ یہ وہ چیز ہے جس پر عمل درآمد کے فوراً بعد فائدہ ہوتا ہے۔ اس قسم کے استعمال کے معاملے میں mypy جیسے علیحدہ قسم کی جانچ پڑتال کے نظام کی ضرورت نہیں ہے، حالانکہ یہ یاد رکھنا چاہیے کہ mypy قسم کی تشریحات کو کوڈ کے مطابق رکھنے میں مدد کرتا ہے۔

mypy کا پس منظر

mypy کی تاریخ برطانیہ میں، کیمبرج میں شروع ہوئی، میرے ڈراپ باکس میں شامل ہونے سے چند سال پہلے۔ میں اپنی ڈاکٹریٹ کی تحقیق کے حصے کے طور پر، جامد ٹائپ شدہ اور متحرک زبانوں کے اتحاد میں شامل رہا ہوں۔ میں جیریمی سیک اور ولید طحہ کے انکریمنٹل ٹائپنگ پر ایک مضمون اور ٹائپڈ ریکیٹ پروجیکٹ سے متاثر ہوا۔ میں نے مختلف پروجیکٹس کے لیے ایک ہی پروگرامنگ لینگویج کو استعمال کرنے کے طریقے تلاش کرنے کی کوشش کی - چھوٹے اسکرپٹس سے لے کر کوڈ بیس تک جس میں لاکھوں لائنوں پر مشتمل ہے۔ ساتھ ہی میں اس بات کو یقینی بنانا چاہتا تھا کہ کسی بھی پیمانے کے پروجیکٹ میں کسی کو بہت بڑا سمجھوتہ نہیں کرنا پڑے گا۔ اس سب کا ایک اہم حصہ ایک غیر ٹائپ شدہ پروٹو ٹائپ پروجیکٹ سے بتدریج جامع طور پر ٹیسٹ شدہ جامد طور پر ٹائپ شدہ تیار شدہ مصنوعات کی طرف جانے کا خیال تھا۔ ان دنوں، ان خیالات کو بڑی حد تک قدر کی نگاہ سے دیکھا جاتا ہے، لیکن 2010 میں یہ ایک ایسا مسئلہ تھا جس کی ابھی بھی سرگرمی سے تحقیق کی جا رہی تھی۔

ٹائپ چیکنگ میں میرا اصل کام ازگر کا مقصد نہیں تھا۔ اس کے بجائے، میں نے ایک چھوٹی "گھریلو" زبان استعمال کی۔ الور. یہاں ایک مثال ہے جو آپ کو سمجھنے دے گی کہ ہم کس کے بارے میں بات کر رہے ہیں (قسم کی تشریحات یہاں اختیاری ہیں):

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

ایک آسان مادری زبان کا استعمال سائنسی تحقیق میں استعمال ہونے والا ایک عام طریقہ ہے۔ ایسا ہے، کم از کم اس لیے نہیں کہ یہ آپ کو تیزی سے تجربات کرنے کی اجازت دیتا ہے، اور اس حقیقت کی وجہ سے بھی کہ جس چیز کا تحقیق سے کوئی تعلق نہیں ہے اسے آسانی سے نظر انداز کیا جا سکتا ہے۔ حقیقی دنیا کی پروگرامنگ زبانیں پیچیدہ نفاذ کے ساتھ بڑے پیمانے پر مظاہر ہوتی ہیں، اور اس سے تجربات سست ہو جاتے ہیں۔ تاہم، آسان زبان پر مبنی کوئی بھی نتیجہ قدرے مشکوک نظر آتا ہے، کیونکہ ان نتائج کو حاصل کرنے میں محقق نے زبانوں کے عملی استعمال کے لیے اہم تحفظات کی قربانی دی ہو گی۔

الور کے لیے میرا ٹائپ چیکر بہت امید افزا لگ رہا تھا، لیکن میں اصلی کوڈ کے ساتھ تجربہ کر کے اس کی جانچ کرنا چاہتا تھا، جو آپ کہہ سکتے ہیں، الور میں نہیں لکھا گیا تھا۔ خوش قسمتی سے میرے لیے، الور زبان زیادہ تر انہی خیالات پر مبنی تھی جیسے ازگر۔ ٹائپ چیکر کو دوبارہ بنانا کافی آسان تھا تاکہ یہ Python کے نحو اور سیمنٹکس کے ساتھ کام کر سکے۔ اس سے ہمیں اوپن سورس ازگر کوڈ میں ٹائپ چیک کرنے کی اجازت ملی۔ اس کے علاوہ، میں نے الور میں لکھے ہوئے کوڈ کو ازگر کوڈ میں تبدیل کرنے کے لیے ایک ٹرانسپلر لکھا اور اسے اپنے ٹائپ چیکر کوڈ کا ترجمہ کرنے کے لیے استعمال کیا۔ اب میرے پاس ایک ٹائپ چیکنگ سسٹم تھا جو ازگر میں لکھا ہوا تھا جو ازگر کے ذیلی سیٹ کو سپورٹ کرتا تھا، اس قسم کی زبان! (کچھ آرکیٹیکچرل فیصلے جو الور کے لیے معنی خیز تھے، ازگر کے لیے مناسب نہیں تھے، اور یہ اب بھی mypy codebase کے کچھ حصوں میں نمایاں ہے۔)

درحقیقت، میرے ٹائپ سسٹم کے ذریعے سپورٹ کی جانے والی زبان کو اس مقام پر ازگر نہیں کہا جا سکتا ہے: یہ Python 3 قسم کے تشریحی نحو کی کچھ حدود کی وجہ سے Python کی ایک قسم تھی۔

یہ جاوا اور ازگر کے مرکب کی طرح لگتا تھا:

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

اس وقت میرے خیالات میں سے ایک یہ تھا کہ اس قسم کے ازگر کو C، یا شاید JVM bytecode کو مرتب کرکے کارکردگی کو بہتر بنانے کے لیے ٹائپ تشریحات کا استعمال کیا جائے۔ میں ایک کمپائلر پروٹوٹائپ لکھنے کے مرحلے پر پہنچ گیا، لیکن میں نے اس خیال کو ترک کر دیا، کیونکہ ٹائپ چیکنگ خود کافی مفید لگ رہی تھی۔

میں نے سانتا کلارا میں PyCon 2013 میں اپنا پروجیکٹ پیش کرنا ختم کیا۔ میں نے اس کے بارے میں گائیڈو وان روسم سے بھی بات کی، جو زندگی کے لیے خیر خواہ پائتھن آمر ہے۔ اس نے مجھے اپنے نحو کو چھوڑنے اور معیاری Python 3 نحو کے ساتھ قائم رہنے پر راضی کیا۔ Python 3 فنکشن تشریحات کو سپورٹ کرتا ہے، لہذا میری مثال کو دوبارہ لکھا جا سکتا ہے جیسا کہ ذیل میں دکھایا گیا ہے، جس کے نتیجے میں ایک عام Python پروگرام ہے:

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

مجھے کچھ سمجھوتہ کرنا پڑا (سب سے پہلے، میں یہ نوٹ کرنا چاہتا ہوں کہ میں نے اسی وجہ سے اپنا نحو ایجاد کیا تھا)۔ خاص طور پر، Python 3.3، اس وقت زبان کا سب سے حالیہ ورژن، متغیر تشریحات کی حمایت نہیں کرتا تھا۔ میں نے گائیڈو کے ساتھ ای میل کے ذریعے اس طرح کے تشریحات کے نحوی ڈیزائن کے لیے مختلف امکانات پر تبادلہ خیال کیا۔ ہم نے متغیرات کے لیے قسم کے تبصرے استعمال کرنے کا فیصلہ کیا۔ اس نے مطلوبہ مقصد کو پورا کیا، لیکن کچھ بوجھل تھا (Python 3.6 نے ہمیں ایک اچھا نحو دیا):

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)

اس سے معلوم ہوا کہ ان (اور دیگر) ٹریڈ آف سے کوئی فرق نہیں پڑتا ہے - جامد ٹائپنگ کے فوائد کا مطلب یہ ہے کہ صارفین جلد ہی کم سے کم نحو کے بارے میں بھول گئے۔ چونکہ Python کوڈ میں کوئی خاص نحو استعمال نہیں کیا گیا تھا جسے ٹائپ چیک کیا گیا تھا، اس لیے موجودہ Python ٹولز اور کوڈ پروسیسنگ کے عمل معمول کے مطابق کام کرتے رہے، جس سے ڈویلپرز کے لیے نئے ٹول کو سیکھنا بہت آسان ہو جاتا ہے۔

اپنے گریجویٹ تھیسس کو مکمل کرنے کے بعد گائیڈو نے مجھے ڈراپ باکس میں شامل ہونے کے لیے بھی قائل کیا۔ یہیں سے mypy کہانی کا سب سے دلچسپ حصہ شروع ہوتا ہے۔

جاری رکھنا ...

پیارے قارئین! اگر آپ Python استعمال کرتے ہیں، تو براہ کرم ہمیں ان پروجیکٹس کے پیمانے کے بارے میں بتائیں جو آپ اس زبان میں تیار کرتے ہیں۔

Python کوڈ کی 4 ملین لائنوں کو ٹائپ چیک کرنے کا راستہ۔ حصہ 1
Python کوڈ کی 4 ملین لائنوں کو ٹائپ چیک کرنے کا راستہ۔ حصہ 1

ماخذ: www.habr.com

نیا تبصرہ شامل کریں