ایکسیپشنز، کلاسز اور اسٹینڈرڈ لائبریری

9 / 3 کوئی ایکسیپشن (例外) پیدا نہیں کرتا، اس لیے except میں داخل نہیں ہوا جاتا۔ else کلاز (else節) صرف تب چلتا ہے جب کوئی ایکسیپشن نہ آیا ہو، اس لیے try کے بعد else چلتا ہے۔ finally کلاز (finally節) ایکسیپشن آنے یا نہ آنے سے قطع نظر ہمیشہ چلتا ہے، اس لیے سب سے آخر میں چلتا ہے۔ چنانچہ 3 لائنیں try، else، finally ہیں۔ except والا انتخاب اس صورت کی ترتیب ہے جب غلطی سے سمجھ لیا جائے کہ ایکسیپشن آیا ہے؛ اس کال میں ZeroDivisionError نہیں آتا۔ finally سے خالی انتخاب وہ ترتیب ہے جو finally کو غلطی سے "ایکسیپشن آنے کی صورت میں صفائی کا کام" سمجھنے پر بنتی ہے۔

try اسٹیٹمنٹ کا else کلاز (else節) صرف تب چلتا ہے جب try کلاز کوئی ایکسیپشن (例外) پیدا کیے بغیر آخر تک مکمل ہو جائے۔ یہ یاد رکھنا مفید ہے کہ یہ if اسٹیٹمنٹ کے else سے، جو "شرط غلط ہونے کی صورت" کے لیے ہے، الٹی سمت میں ہے: try کا else "کام ٹھیک ہو جانے کی صورت" کی طرف ہے۔ ایکسیپشن آنے پر چلنے والا except کلاز ہے۔ ایکسیپشن آنے یا نہ آنے سے قطع نظر ہمیشہ چلنے والا تو finally کلاز ہے۔ جب کوئی بھی except کلاز میل نہ کھائے تو عمل else میں نہیں جاتا؛ وہ ایکسیپشن آگے کال کرنے والے تک منتقل ہو جاتا ہے۔

f() لوٹانے والی ویلیو تیار کر لیتا ہے، لیکن حقیقت میں واپس جانے سے پہلے finally کلاز (finally節) چلاتا ہے۔ اس لیے پہلے F پرنٹ ہوتا ہے، اور ریٹرن ویلیو (戻り値) T ہی رہتی ہے۔ g() کے finally کلاز کے اندر return ہے، اور وہ try کلاز کے return کو اوور رائٹ کر دیتا ہے، اس لیے ریٹرن ویلیو N بن جاتی ہے۔ print پہلے f() اور g() کو evaluate کرتا ہے اور پھر انہیں ایک ہی لائن میں ظاہر کرتا ہے، اس لیے F والی لائن پہلے اور T N والی لائن بعد میں آتی ہے۔ T T والا انتخاب اس صورت کا جواب ہے جب آپ سمجھیں کہ finally کا return نظرانداز ہو جاتا ہے، اور F کے بعد میں آنے والا انتخاب اس صورت کا جواب ہے جب آپ سمجھیں کہ finally، return کے بعد چلتا ہے۔

KeyboardInterrupt براہِ راست BaseException کے نیچے ہے؛ یہ Exception سے وراثت (継承) نہیں لیتا۔ issubclass(KeyboardInterrupt, Exception) کی ویلیو False ہے۔ یہ اس وقت کے لیے ہے جب صارف Ctrl-C سے پروگرام روکنے کی کوشش کرے، اس لیے درجہ بندی (階層) الگ رکھی گئی ہے تاکہ وسیع انداز میں لکھا گیا except Exception اسے غلطی سے نگل نہ جائے۔ SystemExit بھی اسی مقام پر ہے۔ باقی 3 سب Exception کی اولاد ہیں: ZeroDivisionError، ArithmeticError کے نیچے؛ FileNotFoundError، OSError کے نیچے؛ اور ModuleNotFoundError، ImportError کے نیچے ہے، اس لیے یہ سب except Exception سے پکڑے (捕捉) جا سکتے ہیں۔

IndexError اور KeyError دونوں کی نوعیت ایک ہی ہے، یعنی انڈیکس یا key سے کچھ تلاش کرنا اور نہ پانا، اس لیے انہیں مشترکہ پیرنٹ LookupError کے نیچے رکھا گیا ہے۔ except LookupError لکھنے سے لسٹ پر حد سے باہر رسائی اور ڈکشنری میں غیر موجود key، دونوں کو ایک ساتھ پکڑا جا سکتا ہے۔ ArithmeticError، ZeroDivisionError جیسی چیزوں کی پیرنٹ کلاس (親クラス) ہے، ان صورتوں کے لیے جہاں حساب بذاتِ خود ممکن نہ ہو۔ AttributeError تب آتا ہے جب ایٹریبیوٹ (属性) نہ ملے، اور ReferenceError تب جب weak reference (弱参照) کا ہدف ختم ہو چکا ہو؛ یہ دونوں براہِ راست Exception کے نیچے ہیں اور LookupError سے الگ سلسلے سے تعلق رکھتے ہیں۔

8 / 0 سے ZeroDivisionError آتا ہے، لیکن ZeroDivisionError، ArithmeticError کی چائلڈ کلاس (子クラス) ہے۔ except کلازز اوپر سے ترتیب وار ملائے جاتے ہیں، اور پہلی میل کھانے والی جگہ پر ملانا رک جاتا ہے، اس لیے پہلے لکھا گیا except ArithmeticError اسے پکڑ لیتا ہے، اور صرف A پرنٹ ہوتا ہے۔ بعد والے except ZeroDivisionError کی باری ہی نہیں آتی۔ میل کھانے والا صرف ایک except چلتا ہے، اس لیے A اور Z دونوں کا پرنٹ ہونا ممکن نہیں۔ اصول یہ ہے کہ تنگ دائرے والی (چائلڈ کلاس) پہلے اور وسیع دائرے والی (پیرنٹ کلاس) بعد میں رکھی جائے، اور اس سوال کے کوڈ میں یہ ترتیب الٹ دی گئی ہے۔

except کے بعد گول بریکٹس میں ٹیوپل (タプル) لکھنے سے، ان میں سے کوئی بھی ایک میل کھائے تو وہ کلاز چلتا ہے۔ conv("21") میں int("21") کی ویلیو 21 ہے، اس لیے یہ 42 لوٹاتا ہے۔ conv("abc") کو اسٹرنگ کے طور پر پاس تو کیا جا سکتا ہے لیکن عدد کے طور پر سمجھا نہیں جا سکتا، اس لیے ValueError آتا ہے۔ conv(None) ایسی ٹائپ نہیں جو int() کو پاس کی جا سکے، اس لیے TypeError آتا ہے۔ یہ فرق — ٹائپ درست مگر ویلیو نامناسب ہو تو ValueError، اور ٹائپ ہی میل نہ کھائے تو TypeError — بالکل جواب کی ترتیب ہے۔

except بلاک کے اندر بغیر آرگیومنٹ کے صرف raise لکھنے سے اس وقت زیرِ عمل ایکسیپشن جوں کا توں کال کرنے والے کی طرف دوبارہ raise (再送出) ہو جاتا ہے۔ اس لیے inner پرنٹ ہونے کے بعد LoadError، load() سے باہر منتقل ہوتا ہے، اور بیرونی except Exception اسے پکڑ لیتا ہے۔ LoadError، Exception سے وراثت (継承) لیتا ہے، اس لیے except Exception اسے پکڑ سکتا ہے اور پروگرام نہیں رکتا۔ type(e).__name__ اس ایکسیپشن کلاس کا نام لوٹاتا ہے جو حقیقت میں raise ہوئی تھی، اس لیے پکڑنے والی طرف کی ٹائپ کا نام Exception نہیں بلکہ LoadError پرنٹ ہوتا ہے۔ صرف inner کا ظاہر ہونا اس صورت کا آؤٹ پٹ ہوتا جب ایکسیپشن دوبارہ raise کیے بغیر وہیں نگل لیا جاتا۔

پہلی کال لسٹ کا انڈیکس 1 ہے، اس لیے 2 لوٹتا ہے۔ دوسری کال ڈکشنری میں ایسی key تلاش کرتی ہے جو موجود نہیں، اس لیے KeyError آتا ہے، لیکن except میں صرف IndexError لکھا ہے۔ IndexError اور KeyError دونوں LookupError کی چائلڈ کلاسز ہیں، لیکن آپس میں پیرنٹ اور چائلڈ نہیں، اس لیے IndexError والا except، KeyError کو نہیں پکڑ سکتا۔ نہ پکڑا گیا ایکسیپشن (例外) کال کرنے والے کی طرف منتقل ہوتا ہے، اور چونکہ اسے وصول کرنے والا کوئی نہیں، اس لیے پروگرام رک جاتا ہے۔ اگر دونوں کو پکڑنا ہو تو except LookupError لکھیں، یا دونوں کو ٹیوپل میں ساتھ ساتھ رکھیں۔

assert condition, message شرط غلط ہونے پر AssertionError raise (送出) کرتا ہے۔ شرط درست ہو تو کچھ نہیں ہوتا۔ اہم بات یہ ہے کہ python3 -O جیسے آپٹیمائزڈ موڈ (最適化モード) میں شروع کرنے پر assert اسٹیٹمنٹ پوری کی پوری ہٹا دی جاتی ہے، اور اس کی ایک لائن بھی نہیں چلتی۔ اس لیے صارف کے ان پٹ کی جانچ کے مقصد سے assert استعمال نہیں کرنا چاہیے؛ اس مقصد کے لیے if سے شرط جانچ کر raise ValueError(...) کریں۔ بہتر یہ ہے کہ assert کو ڈیولپمنٹ کے دوران اندرونی مفروضات درج کرنے کا آلہ سمجھ کر یاد رکھیں اور یہ کردار الگ رکھیں۔

جب آپ d.speak() لکھتے ہیں تو Python کال کرنے سے پہلے اسے Dog.speak(d) کے طور پر پڑھتا ہے۔ یہاں پہلے آرگیومنٹ کی جگہ پر وہی انسٹینس (インスタンス) آتا ہے جس نے کال کی۔ self کا ہجا محض ایک روایت ہے؛ یہ زبان کا مخصوص (reserved) نام نہیں۔ زبان صرف یہ طے کرتی ہے کہ پہلے آرگیومنٹ کی پوزیشن خود انسٹینس وصول کرتی ہے، اس لیے Dog.speak(d) خود لکھنے پر بھی یہ اسی طرح کام کرتا ہے۔ انسٹینس بنا کر لوٹانا __new__ اور کلاس کو کال کرنے کے نظام کا کام ہے، اور __init__ صرف پہلے سے بنے ہوئے انسٹینس کو initialize (初期化) کرتا ہے۔ پیرنٹ کلاس کا حوالہ دینے کے لیے super() استعمال ہوتا ہے۔

kind براہِ راست class کے نیچے لکھا گیا کلاس ویری ایبل (クラス変数) ہے، اور اس کلاس سے بننے والے تمام انسٹینسز ایک ہی چیز کو شیئر کرتے ہیں۔ نہ a کے اپنے __dict__ میں kind ہے نہ b کے، اس لیے ایٹریبیوٹ پڑھتے وقت دونوں کلاس تک جا کر ایک ہی ویلیو دیکھتے ہیں۔ Dog.kind کو دی گئی ویلیو اسی ایک مشترکہ ویلیو کو بدل دیتی ہے، اس لیے پہلے سے بنے ہوئے a اور b دونوں سے wolf نظر آتا ہے۔ چونکہ انسٹینس بنتے وقت ویلیو کاپی نہیں ہوتی، اس لیے وہ انتخابات درست نہیں جن میں canine باقی رہتا ہے۔

a.kind کو ویلیو اسائن کرنا کلاس ویری ایبل (クラス変数) کو نہیں بدلتا؛ یہ a کی انسٹینس ڈکشنری میں kind نام کی ایک نئی entry بناتا ہے۔ اس کے بعد a.kind پڑھنے پر پہلے یہی نئی entry ملتی ہے، جو کلاس ویری ایبل پر سایہ ڈال دیتی ہے۔ b اور Dog.kind اصل canine ہی رہتے ہیں۔ چنانچہ a.__dict__ میں __init__ کی رکھی ہوئی name کے ساتھ kind بھی آ جاتا ہے، اور sort کرنے پر ['kind', 'name'] ملتا ہے۔ سب کچھ husky ہو جانے والا انتخاب اس صورت کا جواب ہے جب غلطی سے سمجھا جائے کہ انسٹینس کو ویلیو دینے سے کلاس ویری ایبل بدل جاتا ہے، اور صرف ['name'] والا انتخاب اس صورت کا جواب ہے جب سمجھا جائے کہ کوئی سایہ نہیں بنتا۔

self.items.append(x)، self.items کو ویلیو اسائن کرنا نہیں؛ یہ صرف self.items کے ذریعے پہنچے ہوئے آبجیکٹ پر ایک میتھڈ کال کرنا ہے۔ نہ p کی اپنی items ہے نہ q کی، اس لیے دونوں جس چیز تک پہنچتے ہیں وہ کلاس ویری ایبل (クラス変数) کے طور پر رکھی گئی وہی ایک لسٹ ہے۔ نتیجتاً p کے ذریعے ڈالا گیا 1 اور q کے ذریعے ڈالا گیا 2 دونوں اسی لسٹ میں جاتے ہیں، اور جس طرف سے بھی دیکھیں [1, 2] نظر آتا ہے۔ اگر ہر انسٹینس کے لیے الگ برتن چاہیے تو __init__ کے اندر self.items = [] لکھ کر ویلیو اسائن کریں۔ تب یہ [1] اور [2] میں الگ ہو جائے گا۔

Cat کا __init__، super().__init__(name) کو کال کرتا ہے، اس لیے پیرنٹ Animal اس کے لیے self.name سیٹ کر دیتا ہے۔ اس کے بعد self.color میں black رکھا جاتا ہے، اس لیے دونوں ایٹریبیوٹس اپنی جگہ آ جاتے ہیں۔ cry کو چائلڈ کلاس میں دوبارہ define کیا گیا ہے، اس لیے پیرنٹ کا implementation اوور رائیڈ ہو جاتا ہے، اور اس کی جگہ meow والا کال ہوتا ہے۔ isinstance(c, Animal) کی ویلیو True ہے، کیونکہ Cat واقعی Animal سے وراثت (継承) لیتا ہے۔ اگر super() لکھنا بھول جائیں تو name کبھی سیٹ نہیں ہوگا اور AttributeError آئے گا، اس لیے یہ خاموشی سے اس طرح ناکام نہیں ہوتا کہ نتیجہ None نکلے۔

میتھڈ ریزولیوشن آرڈر (メソッド解決順序) سادہ depth-first تلاش (深さ優先) سے نہیں بلکہ C3 linearization (C3線形化) نامی اصول سے طے ہوتا ہے۔ مشترکہ پیرنٹ A کو ان تمام چائلڈ کلاسز کے بعد رکھا جاتا ہے جو A سے وراثت لیتی ہیں، اس لیے ترتیب D، B، C، A، object بنتی ہے۔ اگر یہ depth-first ہوتا، یعنی B میں جا کر سیدھا A تک، تو ترتیب D، B، A، C، object ہوتی، لیکن ایسا نہیں ہوتا، اور یہی احتیاط کا نکتہ ہے۔ who() کو MRO کے شروع سے تلاش کیا جاتا ہے اور جو پہلے ملے وہی استعمال ہوتا ہے، اس لیے B لوٹتا ہے۔ اگر آپ class E(C, B) لکھیں تو ترتیب E، C، B، A، object بنتی ہے؛ جو پہلے لکھا جائے اسے ترجیح ملتی ہے۔

C3 linearization (C3線形化) کے دو اصول ہیں: بیس کلاسز (基底クラス) جس ترتیب سے لکھی گئی ہوں وہ برقرار رکھی جائے، اور پیرنٹ کو اس کی چائلڈ کلاسز کے بعد رکھا جائے۔ F(A, B) کہتا ہے کہ A کو B سے پہلے رکھا جائے، لیکن B، A کی چائلڈ کلاس ہے، اس لیے پیرنٹ A کو چائلڈ B کے بعد آنا چاہیے۔ چونکہ یہ دونوں بیک وقت پوری نہیں ہو سکتیں، اس لیے یہ فیصلہ ہوتا ہے کہ ایک ہم آہنگ MRO نہیں بنایا جا سکتا، اور کلاس کی تعریف evaluate ہوتے ہی TypeError آتا ہے۔ یہ صرف چلانے کی کوشش پر نہیں بلکہ class اسٹیٹمنٹ پراسیس ہوتے ہی ناکام ہو جاتا ہے۔ درست طریقہ یہ ہے کہ class F(B, A) کی طرح چائلڈ کلاس پہلے لکھی جائے۔

ایک انڈر اسکور سے شروع ہونے والا _one صرف ایک روایت ہے جو بتاتی ہے کہ یہ اندرونی استعمال کے لیے ہے، اور اس کا نام نہیں بدلتا؛ اسے باہر سے عام طریقے سے پڑھا جا سکتا ہے۔ دو انڈر اسکورز سے شروع ہونے والے __two پر نیم مینگلنگ (名前修飾) لاگو ہوتی ہے، اور اس کے ایٹریبیوٹ کا اصل نام بدل کر _P__two، یعنی _ClassName__name، ہو جاتا ہے۔ اس لیے p.__two لکھنے پر AttributeError آتا ہے، لیکن p._P__two لکھنے سے اسے پڑھا جا سکتا ہے۔ __dict__ میں بھی بدلا ہوا نام ہی ہوتا ہے، اس لیے sort کرنے پر ['_P__two', '_one'] ملتا ہے۔ صرف دو انڈر اسکورز سے شروع ہونے والے نام بدلے جاتے ہیں؛ _one اس کے دائرے میں نہیں آتا۔

print(v) اور str(v)، __str__ استعمال کرتے ہیں، اس لیے نتیجہ V(1, 2) ہوتا ہے۔ البتہ جب لسٹ یا ڈکشنری جیسے کنٹینر کے اندر رکھ کر ظاہر کیا جائے تو ہر عنصر کے لیے __repr__ استعمال ہوتا ہے، اس لیے نتیجہ [Vec(x=1, y=2)] ہوتا ہے۔ استعمال کا یہی فرق اس سوال کا اہم نکتہ ہے۔ len(v)، __len__ کا لوٹایا ہوا 2 ہے، اور v + Vec(3, 4)، __add__ کا لوٹایا ہوا ایک نیا Vec ہے؛ اسے print کو دینے پر پھر __str__ استعمال ہوتا ہے، اس لیے V(4, 6) ظاہر ہوتا ہے۔ جس کلاس میں __str__ define نہ ہو اس میں اس کی جگہ __repr__ استعمال ہوتا ہے، لیکن اس کا الٹ — __repr__ کی جگہ __str__ کا استعمال — کبھی نہیں ہوتا۔

چونکہ __eq__ define کیا گیا ہے، اس لیے p == q ایٹریبیوٹ x کا موازنہ کر کے True دیتا ہے، لیکن p اور q الگ الگ بنائے گئے آبجیکٹس ہیں، اس لیے p is q بدستور False رہتا ہے۔ یہاں اہم نکتہ یہ ہے کہ جو کلاس __eq__ define کرے اس کا __hash__ خود بخود None سیٹ ہو جاتا ہے، اس لیے Point.__hash__ is None کی ویلیو True ہے۔ جس آبجیکٹ کا ہیش (ハッシュ) نہ ہو اسے سیٹ (集合) میں یا ڈکشنری کی key کے طور پر استعمال نہیں کیا جا سکتا، اس لیے {p, q} بنانے کی کوشش پر TypeError آتا ہے۔ اگر اسے سیٹ میں بھی ڈالنا ہو تو آپ کو اپنا __hash__ define کرنا ہوگا جو برابر آبجیکٹس کے لیے ایک ہی ویلیو لوٹائے۔

math.sqrt پورا تقسیم ہونے کی صورت میں بھی float لوٹاتا ہے، اس لیے 16 کا جذر (平方根) 4 کے بجائے 4.0 ظاہر ہوتا ہے۔ math.floor عددی لکیر پر نیچے کی طرف گول کرتا ہے (切り捨て)، اس لیے -1.5 کا نتیجہ -2 ہے، اور math.ceil اوپر کی طرف گول کرتا ہے، اس لیے -1.5 کا نتیجہ -1 ہے۔ یاد رکھیں کہ منفی اعداد میں 0 کی طرف گول کرنے والا int(-1.5) کا نتیجہ -1 ہوتا ہے، جو floor کے نتیجے سے مختلف ہے۔ floor اور ceil کو آپس میں الٹ سمجھ لیا جائے تو ترتیب -1 -2 بنتی ہے، اور sqrt کی ریٹرن ٹائپ int فرض کی جائے تو 4 ملتا ہے۔

os.path.splitext صرف ایکسٹینشن (拡張子) کو الگ کرتا ہے، ڈاٹ کو ایکسٹینشن والی طرف لگا رہنے دیتا ہے، اور 2 عناصر کا ٹیوپل لوٹاتا ہے۔ اس لیے نتیجہ ('/tmp/z', '.txt') ہوتا ہے۔ ڈاٹ ہٹ کر 'txt' بن جائے، ایسا نہیں ہوتا۔ os.path.basename، path کے آخر کا نام لوٹاتا ہے، اس لیے یہ 'z.txt' ہے۔ ڈائریکٹری والی طرف '/tmp' لوٹانے والا تو os.path.dirname ہے، اور جب دونوں ایک ساتھ ٹیوپل میں چاہییں تو os.path.split استعمال ہوتا ہے۔ یہ فرق یاد رکھنا مفید ہے کہ splitext ڈائریکٹری کے separator پر نہیں بلکہ ایکسٹینشن پر تقسیم کرتا ہے۔

re.match صرف اسٹرنگ کے شروع سے match (照合) کرتا ہے، اس لیے چونکہ 'abc' کا شروع 'a' ہے، یہ 'b' سے match نہیں ہوتا اور None لوٹاتا ہے۔ re.search درمیان میں بھی تلاش کرتا ہے، اس لیے یہ 'b' سے match ہو جاتا ہے، اور .group() سے match ہونے والی اسٹرنگ b نکالی جا سکتی ہے۔ یہ فرق re کے بارے میں سب سے زیادہ پوچھا جانے والا نکتہ ہے۔ re.findall پیٹرن سے match ہونے والے تمام حصے جمع کر کے لسٹ لوٹاتا ہے، اور چونکہ \d+ کا مطلب مسلسل ہندسے ہے، اس لیے نتیجہ ['1', '22', '333'] ہوتا ہے۔ درمیان کے الگ کرنے والے کیریکٹرز شامل نہیں ہوتے۔ اگر کوئی match نہ ہو تو خالی لسٹ لوٹتی ہے۔

date آبجیکٹ کو براہِ راست print کرنے پر یہ ISO فارمیٹ میں، ہائفن کے ساتھ، 2026-08-22 کی شکل میں ظاہر ہوتا ہے۔ فارمیٹ بدلنے کے لیے strftime استعمال ہوتا ہے، اور اسے '%Y/%m/%d' دینے پر سلیش سے الگ کی گئی اسٹرنگ 2026/08/22 لوٹتی ہے۔ date میں timedelta(days=10) جمع کرنے پر timedelta نہیں بلکہ 10 دن بعد کی طرف اشارہ کرنے والا نیا date لوٹتا ہے، اس لیے اسے print کرنے پر 2026-09-01 ملتا ہے۔ مہینے کی حد پار کرنے والے حساب کا خیال datetime خود رکھتا ہے، اس لیے یہ 2026-08-32 جیسی غیر موجود تاریخ نہیں بنتی، جو صرف دن کے عدد میں 10 جمع کرنے سے بنتی۔ اگر آپ سمجھیں کہ print(d) بھی strftime والا فارمیٹ استعمال کرتا ہے تو سلیش والے آؤٹ پٹ قطار میں آئیں گے، لیکن ڈیفالٹ ڈسپلے میں ہائفن ہوتے ہیں۔ جب ایک date میں سے دوسرا date منفی کیا جائے تو date نہیں بلکہ timedelta لوٹتا ہے، اور اس کا ڈسپلے 10 days, 0:00:00 جیسی شکل کا ہوتا ہے۔

'abracadabra' میں a کی تعداد 5 ہے، b اور r ہر ایک 2 بار ہیں، اور c اور d ہر ایک ایک بار۔ most_common(2) تعداد کے لحاظ سے صرف اوپر کے 2 کو، عنصر اور تعداد کے ٹیوپلز کی لسٹ کی شکل میں لوٹاتا ہے، اس لیے نتیجہ [('a', 5), ('b', 2)] ہے۔ برابر تعداد والے b اور r میں سے جو پہلے ظاہر ہوا وہ آگے آتا ہے، اس لیے b چنا جاتا ہے۔ Counter ڈکشنری (辞書) ہی کی ایک قسم ہے، لیکن موجود نہ ہونے والا عنصر تلاش کرنے پر KeyError نہیں آتا؛ یہ 0 لوٹاتا ہے، اور یہی عام ڈکشنری سے فرق ہے۔ اس ڈیزائن کی وجہ سے گنتی سے پہلے موجودگی جانچنے کی ضرورت نہیں رہتی۔

namedtuple سے بنائی گئی ٹائپ ظاہر کرنے پر ٹائپ کے نام اور فیلڈز کے ناموں کے ساتھ Pt(x=1, y=2) کی شکل میں آتی ہے۔ ویلیو نام سے بھی پڑھی جا سکتی ہے اور انڈیکس سے بھی، اس لیے p.x اور p[0] دونوں 1 ہیں۔ اور چونکہ namedtuple، ٹیوپل (タプル) کی ذیلی ٹائپ (派生型) ہے، اس لیے isinstance(p, tuple) کی ویلیو True ہے۔ یعنی یہ ٹیوپل ہی کی ایک قسم ہے، اور اس کے عناصر بعد میں بدلے نہیں جا سکتے۔ اگر بدلی جا سکنے والی ویلیو رکھنی ہو تو یا تو _replace استعمال کریں، جو ایک ویلیو بدل کر نیا انسٹینس بناتا ہے، یا ایک عام کلاس define کریں۔

map جو لوٹاتا ہے وہ لسٹ نہیں بلکہ اٹریٹر (イテレータ) ہے؛ ہر بار next() کال کرنے پر یہ اگلی ویلیو دیتا ہے، اور ختم ہو جانے کے بعد بس ختم۔ چونکہ پہلی list() کال تمام 3 ویلیوز نکال لیتی ہے، اس لیے دوسری list() کال کے لیے کچھ باقی نہیں رہتا، اور یہ خالی لسٹ بن جاتی ہے۔ نہ ایرر آتا ہے نہ None بنتا ہے؛ یہ خاموشی سے خالی ہو جاتی ہے، اس لیے اسے نظرانداز کرنا آسان ہے۔ map(str, ...) ہر عنصر کو اسٹرنگ میں بدلتا ہے، اس لیے پہلا نتیجہ اعداد نہیں بلکہ ['1', '2', '3'] ہے۔ یہی بات filter، zip، enumerate اور جنریٹرز (ジェネレータ) کے ساتھ بھی ہوتی ہے، اس لیے اگر ایک سے زیادہ بار iterate کرنے کا ارادہ ہو تو وصول کرتے ہی list() سے اسے لسٹ میں پکا کر لیں۔

filter کے پہلے آرگیومنٹ کے طور پر None دینے سے یہ عنصر کی اپنی سچائی (真偽) کی بنیاد پر چھانٹی کرتا ہے۔ 0، خالی اسٹرنگ اور None سب false کے طور پر evaluate ہوتے ہیں، اس لیے نکل جاتے ہیں، اور باقی [1, 2, 'a'] رہ جاتا ہے۔ ایسا نہیں کہ نکالے گئے عناصر باقی رہیں۔ all کا اصول یہ ہے کہ اگر ایک بھی false عنصر نہ ہو تو True لوٹائے، اس لیے بالکل عناصر کے بغیر خالی لسٹ کے لیے یہ True ہے۔ any تب True لوٹاتا ہے جب کم از کم ایک true عنصر ہو، اس لیے خالی کے لیے یہ False ہے۔ یہ نکتہ کہ خالی sequence دینے پر یہ دونوں الٹے جواب دیتے ہیں، اکثر پوچھا جاتا ہے۔

yield والے فنکشن کو کال کرنے سے بھی اس کی باڈی کی ایک لائن تک نہیں چلتی۔ واپس صرف ایک جنریٹر آبجیکٹ (ジェネレータオブジェクト) آتا ہے، اس لیے پہلے created پرنٹ ہوتا ہے۔ پہلے next(g) کے ساتھ ہی یہ آخرکار اوپر سے چلنا شروع کرتا ہے، start پرنٹ کرتا ہے، پھر yield 1 پر رک کر 1 لوٹاتا ہے۔ اگلا next(g) وہیں سے دوبارہ شروع ہوتا ہے جہاں رکا تھا، mid پرنٹ کرتا ہے، اور پھر yield 2 پر رک کر 2 لوٹاتا ہے۔ یہ سست عمل درآمد (遅延実行) عام فنکشن سے فیصلہ کن فرق ہے، اور ایک بار اور next(g) کال کرنے سے فنکشن ختم ہو جاتا ہے، جس کا نتیجہ StopIteration ہوتا ہے۔

== وہ آپریٹر (演算子) ہے جو پوچھتا ہے کہ ویلیوز برابر ہیں یا نہیں، اس لیے چونکہ a اور b کا مواد ایک جیسا ہے، نتیجہ True ہے۔ is وہ آپریٹر ہے جو پوچھتا ہے کہ کیا یہ ایک ہی آبجیکٹ ہے، اور چونکہ a اور b الگ الگ بنائی گئی دو لسٹیں ہیں، نتیجہ False ہے۔ دوسری طرف c = a کوئی نئی لسٹ نہیں بناتا؛ یہ صرف اسی آبجیکٹ کو ایک اور نام دیتا ہے، اس لیے a is c کی ویلیو True ہے۔ یعنی c کے ذریعے لسٹ بدلی جائے تو تبدیلی a سے بھی نظر آتی ہے۔ None ایک خاص آبجیکٹ ہے جو صرف ایک ہی بار موجود ہوتا ہے، اس لیے x is None لکھنا معیاری انداز ہے، لیکن جب ویلیوز کا موازنہ کرنا ہو تو ہمیشہ == استعمال کریں۔