ডিবাগিং আর logging — বাগ খোঁজার বিজ্ঞান আর প্রোগ্রামের ডায়েরি

১ · ডিবাগিং মানে বাগের ওপর বৈজ্ঞানিক পদ্ধতি

পর্ব ০২-এ শুনেছিলেন, প্রোগ্রামের ভুলকে বলে bug, আর ভুল খুঁজে ঠিক করার কাজকে বলে debugging. পর্ব ৩৯-এ শিখেছেন pytest দিয়ে টেস্ট লিখতে — টেস্ট বলে দেয় যে কিছু একটা ভুল। কিন্তু টেস্ট লাল হলে বা ব্যবহারকারী অভিযোগ করলে প্রশ্ন আসে: ভুলটা কোথায়, আর কেন? এই পর্ব সেই প্রশ্নের উত্তর খোঁজার পদ্ধতি নিয়ে।

নতুন প্রোগ্রামাররা প্রায়ই একটি ভুল পথে হাঁটেন: কোডের দিকে তাকিয়ে থাকা, একটা কিছু বদলে চালানো, কাজ না হলে আরেকটা কিছু বদলানো। এতে কখনো কখনো বাগ চলে যায়, কিন্তু আপনি জানেন না কেন — আর প্রায়ই দুটি নতুন বাগ ঢুকে যায়। অভিজ্ঞ প্রোগ্রামাররা অন্যভাবে কাজ করেন। তাঁরা বাগটিকে একটি রহস্য হিসেবে দেখেন, আর বিজ্ঞানীর মতো প্রমাণ জোগাড় করেন।

চক্রটি চার ধাপের, আর প্রয়োজনে বারবার ঘোরে:

1. পুনরুৎপাদন (reproduce): বাগটি ইচ্ছেমতো ঘটাতে পারেন এমন একটি নির্দিষ্ট ইনপুট খুঁজুন। যে বাগ ঘটাতে পারেন না, তা ঠিক হয়েছে কি না তাও প্রমাণ করতে পারবেন না।
2. অনুমান (hypothesis): “আমার মনে হয়, লুপটি প্রথম জিনিসটি বাদ দিচ্ছে” — এমন একটি নির্দিষ্ট, যাচাইযোগ্য বাক্য।
3. পরীক্ষা: অনুমানটি সত্য হলে কী দেখার কথা, তা আগে ঠিক করুন, তারপর দেখুন — print, debugger বা একটি ছোট টেস্ট দিয়ে।
4. খোঁজার জায়গা ছোট করা: প্রতিটি পরীক্ষার পর সন্দেহের এলাকা অর্ধেক হওয়া উচিত — ঠিক পর্ব ০২-এর binary search-এর মতো।

নিচে একটি দোকানের বিলের total() ফাংশন। তিনটি জিনিসের দাম ১০০, ২০০ আর ৫০ — যোগফল হওয়ার কথা ৩৫০, কিন্তু আসছে ২৫০. কোড দেখে সাথে সাথে বাগ ধরে ফেললেও থামুন — এখানে লক্ষ্য পদ্ধতিটি দেখা, যা বড় আর অচেনা কোডেও কাজ করবে। “পরে” চাপুন:

1def total(prices):2    s = 03    for i in range(1, len(prices)):4        s += prices[i]5    return s67print(total([100, 200, 50]))   # আশা: 350

একটি অভ্যাস যোগ করুন: যেকোনো মুহূর্তে আপনি কী জানেন, কী অনুমান করছেন আর কী বাদ দিয়েছেন — একটি কাগজে বা টেক্সট ফাইলে লিখে রাখুন। দুই ঘণ্টা ডিবাগিংয়ের পর মাথা ক্লান্ত থাকে, আর একই পরীক্ষা দ্বিতীয়বার করা খুব সাধারণ ভুল।

২ · Traceback পড়া আর ঠিকভাবে print-debugging

প্রথম সূত্র: traceback

প্রোগ্রাম ক্র্যাশ করলে Python যে traceback দেয়, সেটিই আপনার প্রথম প্রমাণ। পর্ব ০৪-এ নিয়মটি শিখেছিলেন: নিচ থেকে ওপরে পড়ুন. শেষ লাইনে exception-এর ধরন আর বার্তা — কী ঘটেছে। তার ঠিক ওপরে যে লাইনে ঘটেছে। আরও ওপরে call stack-এর বাকি frame-গুলো — কোন পথে সেখানে পৌঁছানো হয়েছে। পর্ব ২৪-এ দেখেছেন, প্রতিটি File ... line ... একটি stack frame, যার ভেতর দিয়ে exception ওপরে উঠে এসেছে।

একটি GPA হিসাবের প্রোগ্রাম, যা ৮৫, ৭২ আর ৪০ নম্বর থেকে গড় grade point বের করে, এই traceback দিল:

Traceback (most recent call last):
  File "gpa.py", line 16, in <module>
    print(calc_gpa([85, 72, 40]))
          ~~~~~~~~^^^^^^^^^^^^^^
  File "gpa.py", line 14, in calc_gpa
    return sum(points) / len(points)
           ~~~^^^^^^^^
TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'

শেষ লাইন বলছে: কেউ একটি float-এর সাথে None যোগ করতে চেয়েছে। কোথায়? লাইন ১৪-এর sum(points)-এ — ~~~^^^^^^^^ দাগটি ঠিক সেই অংশের নিচে। এটি Python 3.11-এর fine-grained error location (PEP 657): লম্বা একটি লাইনের কোন অংশে ভুল, তা দাগ দিয়ে দেখায়। আগে শুধু লাইন নম্বর পাওয়া যেত, আর a.b.c.d-এর মতো লাইনে কোনটি None তা আন্দাজ করতে হতো।

কিন্তু traceback বলে কোথায় ক্র্যাশ হয়েছে, বাগটা কোথায় জন্মেছে তা নয়। sum-এর কোনো দোষ নেই; দোষ সেই কোডের, যে points তালিকায় None ঢুকিয়েছে। এটি ডিবাগিংয়ের খুব গুরুত্বপূর্ণ পার্থক্য: লক্ষণের জায়গা আর কারণের জায়গা আলাদা হতে পারে. এখান থেকে প্রশ্ন ওঠে: None-টা কোথা থেকে এল? উত্তর খুঁজব অংশ ৩-এ, debugger দিয়ে।

print-debugging — সবচেয়ে পুরোনো, এখনো কাজের

কোডের মাঝে print বসিয়ে ভেতরের অবস্থা দেখাকে বলে print debugging. একে অনেকে “নবিশদের কৌশল” বলে ছোট করেন, কিন্তু অভিজ্ঞ প্রোগ্রামাররাও প্রতিদিন এটি ব্যবহার করেন — দ্রুত, সব জায়গায় চলে, কোনো সেটআপ লাগে না। শুধু ঠিকভাবে করতে হয়। তিনটি কৌশল:

price, qty = "120", 3
print(price, qty)            # 120 3          ← কোনটি string, বোঝা যায় না
print(f"{price=} {qty=}")    # price='120' qty=3
print(type(price), repr(price))   # <class 'str'> '120'

• f"{x=}" (Python 3.8 থেকে): নাম আর মান একসাথে ছাপে, আর মানটি দেখায় repr রূপে। সাধারণ print(price) দেখায় 120 — সংখ্যা নাকি string, বোঝার উপায় নেই। price='120'-এর উদ্ধৃতিচিহ্ন সাথে সাথে বলে দেয়: এটি string. পাঁচটি print থাকলে কোন লাইন কোন ভ্যারিয়েবলের, সেই বিভ্রান্তিও আর থাকে না।
• repr(): অদৃশ্য জিনিস দৃশ্যমান করে। "Rahim "-এর শেষের ফাঁকা জায়গা, "\n", বা বাংলা লেখার ভেতরের অদৃশ্য অক্ষর print-এ দেখা যায় না, repr-এ দেখা যায়।
• type(): “এটা আসলে কী?” — অর্ধেক বাগের উত্তর এখানেই। যে জিনিসকে আপনি list ভাবছেন, সেটি হয়তো একটি tuple, একটি generator, বা None.

তবে print-debugging-এর সীমা আছে। প্রতিটি নতুন প্রশ্নের জন্য কোড বদলে আবার চালাতে হয় — প্রোগ্রাম চালাতে যদি এক মিনিট লাগে, বা বাগে পৌঁছাতে দশটি ধাপের ইনপুট দিতে হয়, তাহলে খুব ধীর। লুপের ভেতরের print হাজার লাইন ছেপে পর্দা ভাসিয়ে দেয়। আর কাজ শেষে print মুছতে ভুলে গেলে সেগুলো ব্যবহারকারীর পর্দায় বা প্রোডাকশনে চলে যায়। এই সীমাগুলোর দুটি সমাধান: থামিয়ে দেখার জন্য debugger (অংশ ৩–৪), আর স্থায়ীভাবে লিখে রাখার জন্য logging (অংশ ৭–৮)।

৩ · pdb আর breakpoint() — চলন্ত প্রোগ্রামকে থামিয়ে প্রশ্ন করা

print-debugging-এ আপনাকে আগে থেকে ঠিক করতে হয় কী দেখবেন। debugger উল্টো কাজ করে: প্রোগ্রামকে একটি জায়গায় থামিয়ে দেয়, আর তখন আপনি যা খুশি জিজ্ঞেস করতে পারেন — যেকোনো ভ্যারিয়েবলের মান, যেকোনো expression, কোন ফাংশন কাকে ডেকেছে। তারপর এক লাইন এক লাইন করে এগোতে পারেন। পর্ব ০২-এ হাতে যে dry run আর trace table করেছিলেন, debugger সেটিই করে — আসল প্রোগ্রামের ওপর, নির্ভুলভাবে।

Python-এর সাথেই আসে একটি debugger: pdb (Python DeBugger), standard library-র অংশ। একে চালু করার সবচেয়ে সহজ উপায় হলো যেখানে থামতে চান, সেখানে একটি লাইন লেখা: breakpoint(). এই built-in ফাংশনটি এসেছে Python 3.7-এ (PEP 553). আগে লিখতে হতো import pdb; pdb.set_trace() — এখনো কাজ করে, কিন্তু breakpoint() ছোট, আর PYTHONBREAKPOINT=0 environment variable দিয়ে কোড না বদলেই সব breakpoint() বন্ধ করা যায়।

প্রোগ্রাম breakpoint()-এ পৌঁছালে টার্মিনালে (Pdb) prompt আসে। এখানে ছোট ছোট কমান্ড লিখে প্রোগ্রাম চালান:

এবার অংশ ২-এর GPA বাগটি ধরি। calc_gpa-এর শুরুতে একটি breakpoint বসানো হয়েছে। প্রতিটি ধাপে ডানদিকের টার্মিনালে দেখবেন আপনি কী লিখলেন আর pdb কী উত্তর দিল (ফাইলের পথ ছোট করে দেখানো):

1def grade_point(mark):2    if mark >= 80:3        return 4.04    if mark >= 60:5        return 3.06    if mark > 40:7        return 2.089def calc_gpa(marks):10    breakpoint()11    points = []12    for m in marks:13        points.append(grade_point(m))14    return sum(points) / len(points)1516print(calc_gpa([85, 72, 40]))

Post-mortem — ক্র্যাশের পরে লাশ পরীক্ষা

কখনো কখনো আপনি জানেন না কোথায় breakpoint() বসাবেন — প্রোগ্রাম শুধু ক্র্যাশ করে। তখন post-mortem debugging: প্রোগ্রাম মারা যাওয়ার ঠিক মুহূর্তের অবস্থায় debugger খোলা, যখন সব ভ্যারিয়েবল তখনো মেমরিতে আছে। দুটি উপায়:

# উপায় ১: শুরু থেকেই pdb-এর অধীনে চালানো
python -m pdb gpa.py
(Pdb) c          # স্বাভাবিকভাবে চলতে দিন; ক্র্যাশ হলে pdb নিজেই থামবে

# উপায় ২: ক্র্যাশের পর interactive থেকে যাওয়া
python -i gpa.py
>>> import pdb; pdb.pm()

প্রথম উপায়ে না-ধরা exception উঠলে pdb লেখে “Uncaught exception. Entering post mortem debugging” আর ঠিক ক্র্যাশের লাইনে থামে। সেখানে p points লিখলেই দেখবেন [4.0, 3.0, None], আর u/d দিয়ে stack-এ ঘুরে দেখতে পারবেন। দ্বিতীয় উপায়ে -i flag প্রোগ্রাম শেষে (বা ক্র্যাশের পরে) REPL খোলা রাখে, আর pdb.pm() শেষ exception-এর জায়গায় debugger খোলে। Jupyter notebook-এ একই কাজ করে %debug magic.

৪ · VS Code debugger — একই কাজ, চোখের সামনে

pdb সব জায়গায় চলে — সার্ভারে, SSH-এ, যেখানে কোনো গ্রাফিক্স নেই। কিন্তু নিজের কম্পিউটারে প্রতিদিনের কাজে অনেকে IDE-র গ্রাফিক্যাল debugger বেশি আরামদায়ক মনে করেন। পর্ব ০৩-এ VS Code সেটআপ করেছিলেন; Microsoft-এর Python extension-এর সাথে “Python Debugger” extension আসে, যা ভেতরে debugpy ব্যবহার করে। ধারণা হুবহু pdb-এর মতো, শুধু কমান্ডের বদলে বোতাম:

তিনটি সুবিধা আলাদা করে জানা দরকার, কারণ এগুলো সময় সবচেয়ে বেশি বাঁচায়:

• Conditional breakpoint: লাল বিন্দুতে ডান-ক্লিক → “Edit Breakpoint” → শর্ত লিখুন, যেমন m == 40 বা len(cart) > 100. দশ হাজার সারির লুপে যে সারিতে সমস্যা, শুধু সেখানেই থামবে। “Hit Count” দিয়ে “৫০০তম বারে থামো”-ও বলা যায়।
• Watch expression: WATCH প্যানেলে একটি expression লিখে রাখুন — sum(points), order["total"] - paid. প্রতিটি step-এর পর VS Code নিজে আবার হিসাব করে দেখায়। কোন লাইনে মানটি হঠাৎ বদলে গেল, এক নজরে চোখে পড়ে।
• Debug Console: থেমে থাকা অবস্থায় এখানে যেকোনো Python লিখে চালাতে পারেন — এখনকার frame-এর সব ভ্যারিয়েবল হাতের কাছে। “এখানে যদি >= হতো, ফল কী হতো?” — কোড না বদলেই grade_point(40)-এর মতো পরীক্ষা চালিয়ে দেখুন।

আরেকটি সুবিধা হলো logpoint: breakpoint-এর মতোই বসান, কিন্তু থামার বদলে একটি বার্তা ছাপে, যেমন i={i} total={s}. এটি print-debugging, কিন্তু কোডে কোনো লাইন যোগ না করে — মুছতে ভোলার ভয় নেই। আর বিশেষ সেটিং (যেমন command-line argument বা environment variable) দরকার হলে .vscode/launch.json ফাইলে লিখে রাখা যায়, যাতে প্রতিবার F5 চাপলেই একইভাবে চলে।

৫ · Python-এর চেনা বাগ — লক্ষণ দেখে রোগ চেনা

অভিজ্ঞ ডাক্তার অনেক রোগ লক্ষণ দেখেই সন্দেহ করেন, কারণ একই রোগ বারবার দেখেছেন। প্রোগ্রামিংয়েও তাই। Python-এ কয়েকটি বাগ এত ঘনঘন আসে যে এদের লক্ষণ মুখস্থ রাখলে অর্ধেক ডিবাগিং কয়েক সেকেন্ডে শেষ হয়:

দুটি বাস্তব উদাহরণ ভালো করে দেখা যাক। প্রথমটি একটি অনলাইন দোকানের কার্ট — ক্লাসিক mutable default:

def add_to_cart(item, cart=[]):     # বাগ: [] একবারই তৈরি হয়
    cart.append(item)
    return cart

rahim = add_to_cart("চাল")          # ['চাল']
karim = add_to_cart("ডাল")          # ['চাল', 'ডাল']  ← করিমের কার্টে রহিমের চাল!
print(rahim is karim)               # True — দুজনের একটিই কার্ট

লক্ষণটি বিভ্রান্তিকর: একা টেস্ট করলে সব ঠিক, দ্বিতীয় গ্রাহক এলেই গোলমাল। পর্ব ২০-এ দেখেছিলেন কেন — default মান তৈরি হয় def চলার সময় একবারই, প্রতিটি ডাকে নতুন করে নয়। রোগনির্ণয়ের সূত্র হলো is: দুটি ফল একই object হলে আপনি আর অনুমান করছেন না, প্রমাণ পেয়ে গেছেন। প্রতিকার: cart=None.

দ্বিতীয়টি অংশ ৩-এর GPA বাগ, যার মূল রোগ “return ছাড়া পথ”. Python-এ যে ফাংশন কোনো return-এ পৌঁছায় না, সে চুপচাপ None ফেরত দেয় — কোনো সতর্কবার্তা নেই। আর None সাথে সাথে ক্র্যাশ করায় না; সেটি একটি তালিকায় ঢুকে বসে থাকে, আর ক্র্যাশ হয় অনেক পরে, অন্য কোনো লাইনে। এজন্যই পর্ব ৩৭-এর type hint কাজের: def grade_point(mark: int) -> float: লিখলে mypy সাবধান করে দেয় যে কোনো পথে ফাংশনটি None ফেরত দিতে পারে — প্রোগ্রাম চালানোর আগেই।

৬ · আটকে গেলে — রাবার হাঁস, ছোট উদাহরণ আর git bisect

রাবার হাঁসকে বুঝিয়ে বলা

এক ঘণ্টা ধরে আটকে আছেন। একজন সিনিয়রকে ডেকে বোঝাতে শুরু করলেন — “এই লাইনে আমি তালিকাটা নিচ্ছি, তারপর এখানে প্রতিটি দাম… ও আচ্ছা! এখানে তো আমি index 1 থেকে শুরু করেছি।” সিনিয়র একটি কথাও বলেননি, অথচ সমস্যার সমাধান হয়ে গেল। এই অভিজ্ঞতা এত সাধারণ যে এর একটি নাম আছে: rubber duck debugging. Andrew Hunt আর David Thomas-এর The Pragmatic Programmer (১৯৯৯) বইয়ে একটি গল্প আছে — এক প্রোগ্রামার টেবিলে একটি রাবারের হাঁস রাখতেন আর আটকে গেলে হাঁসকে লাইন ধরে ধরে কোড বোঝাতেন। মাথার ভেতরে আমরা ধাপ লাফিয়ে যাই (“এখানে তো ঠিকই আছে”); মুখে বলতে গেলে প্রতিটি ধাপ স্পষ্ট করতে হয়, আর ভুল ধারণা নিজের কানেই ধরা পড়ে। হাঁস না থাকলে চায়ের কাপ, একটি খালি চেয়ার বা একটি নোটবুকও চলবে।

Minimal reproducible example — সাহায্য চাওয়ার শিল্প

নিজে না পারলে সাহায্য চাইবেন — Stack Overflow-এ, কোনো ফোরামে, সহকর্মীকে, বা AI-কে। কিন্তু “আমার কোড কাজ করছে না, এই নিন ৮০০ লাইন” লিখলে কেউ সাহায্য করতে পারে না। যা দরকার তা হলো একটি minimal reproducible example (MRE) — Stack Overflow-এর সহায়তা পাতায় এর তিনটি গুণ বলা আছে:

• Minimal (ক্ষুদ্রতম): যত কম কোডে বাগটি দেখা যায়। ডেটাবেস, ওয়েব ফর্ম, দশটি ফাংশন — বাগ দেখাতে না লাগলে বাদ। calc_gpa([85, 72, 40])-এর বদলে শুধু grade_point(40) যদি None দেয়, সেটিই আপনার MRE.
• Complete (সম্পূর্ণ): অন্য কেউ কপি করে সরাসরি চালাতে পারবে — দরকারি import আর ছোট নমুনা ডেটাসহ। “আমার CSV ফাইলে” নয়; ফাইলের তিনটি সারি কোডের ভেতরেই দিন।
• Reproducible (পুনরুৎপাদনযোগ্য): চালালে সত্যিই বাগটি দেখা যায়। সঙ্গে লিখুন: কী আশা করেছিলেন, কী পেলেন, পুরো traceback, আর Python version.

মজার ব্যাপার হলো, MRE বানাতে গিয়ে প্রায় অর্ধেক সময় প্রশ্ন পোস্ট করার আগেই বাগ খুঁজে পাবেন। কোড ছেঁটে ছোট করা আসলে অংশ ১-এর “খোঁজার জায়গা ছোট করা” — প্রতিটি অংশ বাদ দিয়ে দেখছেন, বাগ থাকে কি না। অংশ ৯-এ দেখবেন, AI-কে প্রশ্ন করার সময়ও ঠিক একই নিয়ম।

git bisect — “কাল তো চলছিল!”

কিছু বাগের ক্ষেত্রে আপনি জানেন, আগের কোনো version ঠিক ছিল। গত তিন সপ্তাহে ২০০টি commit হয়েছে, কোনটি বাগ এনেছে? git bisect এর উত্তর দেয় binary search দিয়ে: আপনি একটি ভালো আর একটি খারাপ commit বলে দেন, git মাঝখানের একটি commit বের করে দেয়, আপনি পরীক্ষা করে বলেন good নাকি bad — প্রতিবার সন্দেহের তালিকা অর্ধেক হয়। ২০০টি commit-এ মাত্র ৮ বার পরীক্ষা লাগে (২^৮ = ২৫৬)। আর বাগ ধরার একটি স্বয়ংক্রিয় টেস্ট থাকলে git bisect run pytest tests/test_cart.py লিখে পুরো খোঁজাটাই git-কে দিয়ে করানো যায়:

git bisect start
git bisect bad              # এখনকার version-এ বাগ আছে
git bisect good v1.4        # এই version ঠিক ছিল
# git একটি commit বের করে দেবে → পরীক্ষা করে লিখুন: git bisect good / bad
git bisect reset            # শেষে আগের জায়গায় ফেরা

৭ · logging — প্রোগ্রামের ডায়েরি, কেন print নয়

এ পর্যন্ত যা শিখলেন সবই আপনার কম্পিউটারে, আপনার চোখের সামনে ঘটা বাগের জন্য। কিন্তু ধরুন আপনার লেখা একটি পেমেন্ট সার্ভিস সার্ভারে চলছে। রাত তিনটায় একজন গ্রাহকের টাকা কেটেছে কিন্তু পেমেন্ট সফল দেখায়নি। সকালে অভিযোগ এল। তখন debugger কোনো কাজে আসবে না — ঘটনা ঘটে গেছে, আর আপনি সেখানে ছিলেন না। একমাত্র ভরসা হলো, প্রোগ্রাম চলার সময় নিজেই লিখে রেখেছিল কী কী ঘটেছে। একে বলে logging.

তাহলে print দিয়েই তো লেখা যায়? না, কারণ বাস্তব প্রোগ্রামে print-এর চারটি বড় অভাব আছে, যা Python-এর logging module পূরণ করে:

• গুরুত্ব (log level): প্রতিটি বার্তার একটি গুরুত্ব থাকে — সাধারণ খবর, সতর্কতা, নাকি জরুরি ভুল। print-এ সবই সমান।
• প্রসঙ্গ: প্রতিটি লাইনে নিজে থেকেই সময়, কোন module থেকে এসেছে, কোন level — আপনাকে প্রতিবার লিখতে হয় না।
• গন্তব্য: একই বার্তা পর্দায়, ফাইলে, বা কোনো log সার্ভারে পাঠানো যায় — শুধু কনফিগারেশন বদলে, কোড না ছুঁয়ে।
• কমানো-বাড়ানো: সাধারণ দিনে শুধু সতর্কতা আর ভুল; সমস্যা খোঁজার দিনে এক লাইন বদলে সব খুঁটিনাটি। ডিবাগের বার্তা কোডেই থেকে যায়, মুছতে হয় না।

পাঁচটি level

Python-এর logging-এ পাঁচটি মানক level, প্রতিটির ভেতরে একটি সংখ্যা:

নিয়মটি সরল: আপনি একটি সীমা (level) ঠিক করে দেন, আর সেই সীমা বা তার চেয়ে বেশি গুরুত্বের বার্তাই দেখা যায়. সীমা WARNING হলে DEBUG আর INFO চুপচাপ বাদ পড়ে। নিচের পাঁচটি log লাইন একই রেখে শুধু সীমা বদলালে কী হয়, দেখুন:

1log.debug("cart=%s", cart)2log.info("অর্ডার 1042 হয়েছে")3log.warning("চালের স্টক কম: 2 কেজি")4log.error("SMS gateway সাড়া দিচ্ছে না")5log.critical("ডেটাবেস বন্ধ")

প্রথম logging প্রোগ্রাম — bKash-ধাঁচের পেমেন্ট

তিনটি জিনিস দিয়ে শুরু: logging.basicConfig() দিয়ে একবার কনফিগারেশন, logging.getLogger(নাম) দিয়ে একটি logger নেওয়া, আর সেই logger-এর .debug(), .info(), .warning(), .error() ডাকা। চালানোর আগে অনুমান করুন — চারটি log ডাকের মধ্যে কোনগুলো ছাপা হবে, আর pin কোথাও দেখা যাবে কি?

import logging
import sys

logging.basicConfig(level=logging.INFO, stream=sys.stdout,
                    format="%(levelname)s:%(name)s:%(message)s")
log = logging.getLogger("wallet.payment")

def pay(balance, amount, pin):
    log.debug("pay() ডাকা হলো: balance=%s amount=%s", balance, amount)
    if amount <= 0:
        log.warning("অবৈধ পরিমাণ বাতিল: %s", amount)
        return balance
    if amount > balance:
        log.error("ব্যালান্স কম: চাওয়া %s, আছে %s", amount, balance)
        return balance
    log.info("পেমেন্ট সফল: %s টাকা, বাকি %s", amount, balance - amount)
    return balance - amount

b = pay(1000, 300, pin="4821")
b = pay(b, -50, pin="4821")
b = pay(b, 5000, pin="4821")

%(levelname)s, %(name)s, %(message)s হলো format-এর জায়গা-রাখা চিহ্ন। আরও আছে %(asctime)s (সময়), %(filename)s, %(lineno)d (কোন ফাইলের কোন লাইন থেকে), %(funcName)s. আর logger-এর নাম হিসেবে বাস্তবে প্রায় সবসময় লেখা হয় logging.getLogger(__name__) — __name__ হলো module-এর নাম (পর্ব ২২), যেমন wallet.payment. তাতে প্রতিটি log লাইন দেখে বোঝা যায় কোন module থেকে এসেছে, আর পরের অংশে দেখবেন, নামের বিন্দুগুলো একটি বংশতালিকাও বানায়।

৮ · logging ঠিকভাবে — ফাইল, traceback, secret আর একবারের কনফিগারেশন

ফাইলে লেখা আর বাস্তব format

পর্দার লেখা প্রোগ্রাম বন্ধ হলেই হারায়; লগবুক রাখতে হয় ফাইলে। বাস্তব অ্যাপের কনফিগারেশন সাধারণত এমন, প্রোগ্রামের প্রবেশদ্বারে (যেমন main.py):

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)-8s %(name)s: %(message)s",
    handlers=[
        logging.FileHandler("app.log", encoding="utf-8"),   # ফাইলে
        logging.StreamHandler(),                             # পর্দায় (stderr)
    ],
)

এখানে নতুন শব্দ handler: বার্তা কোথায় যাবে, তা ঠিক করে handler. FileHandler ফাইলে লেখে, StreamHandler পর্দায়। একটি logger-এর কয়েকটি handler থাকতে পারে, আর প্রতিটির নিজস্ব level ও format থাকতে পারে — যেমন ফাইলে সব DEBUG, পর্দায় শুধু WARNING. বাংলা বার্তার জন্য encoding="utf-8" দিতে ভুলবেন না (পর্ব ২৫)। ফাইল যেন অসীম বড় না হয়, তার জন্য logging.handlers module-এ RotatingFileHandler (আকার ধরে নতুন ফাইল) আর TimedRotatingFileHandler (দিন ধরে নতুন ফাইল) আছে।

logger.exception() — traceback-সহ লেখা

পর্ব ২৪-এ শিখেছিলেন, except-এ ভুল ধরলে অন্তত লিখে রাখতে হয়। কিন্তু log.error(e) লিখলে শুধু বার্তাটি থাকে — কোন লাইনে, কোন পথে ঘটেছিল, তা হারিয়ে যায়। সঠিক উপায়:

try:
    gateway.charge(order_id, amount)
except PaymentError:
    log.exception("অর্ডার %s-এর চার্জ ব্যর্থ", order_id)   # ERROR level + পুরো traceback
    raise                                              # সিদ্ধান্ত ওপরের কোডের

log.exception() লেখে ERROR level-এ, আর বার্তার নিচে পুরো traceback জুড়ে দেয়। এটি শুধু except block-এর ভেতরেই ডাকবেন (বাইরে কোনো চলমান exception নেই)। অন্য level-এ traceback চাইলে log.warning("...", exc_info=True). আর খেয়াল করুন: লগ লিখে খালি raise — ধরেছি শুধু লিখে রাখার জন্য, সামলানোর ক্ষমতা আমার নেই।

Lazy formatting — %s কেন, f-string কেন নয়

এতক্ষণ সব log ডাকে লিখেছি log.info("বাকি %s", balance), f"বাকি {balance}" নয়। কারণ lazy formatting: বার্তা আর মানগুলো আলাদা দিলে logging আগে দেখে বার্তাটি আদৌ ছাপা হবে কি না, আর তবেই string জোড়া লাগায়। সীমা INFO থাকলে log.debug("cart=%s", huge_cart) বিনা খরচে বাদ পড়ে; কিন্তু log.debug(f"cart={huge_cart}")-এ বিশাল string তৈরি হয় আগে, ফেলে দেওয়া হয় পরে। লুপের ভেতরে লাখবার চললে এই পার্থক্য চোখে পড়ার মতো। দ্বিতীয় সুবিধা: সব “পেমেন্ট সফল: %s টাকা” লাইনের ছাঁচ একই থাকে, তাই log বিশ্লেষণের টুলগুলো এদের এক দলে গুনতে পারে। (মনে রাখবেন, এখানেও আর্গুমেন্টগুলো নিজে আগেই হিসাব হয়; খুব দামি হিসাব হলে if log.isEnabledFor(logging.DEBUG): দিয়ে ঘিরে দিন।)

secret কখনো লগে নয়

একবার কনফিগার, প্রবেশদ্বারে — library বনাম application

logging-এর সবচেয়ে গুরুত্বপূর্ণ নকশা-নিয়ম: কোথায় কী লিখবেন (log ডাক) আর লেখাগুলো কোথায়, কীভাবে যাবে (কনফিগারেশন) — দুটি আলাদা জায়গার কাজ। প্রতিটি module শুধু log = logging.getLogger(__name__) নেয় আর বার্তা লেখে। কনফিগারেশন (basicConfig বা logging.config.dictConfig) হয় একবার, প্রোগ্রামের প্রবেশদ্বারে — সাধারণত if __name__ == "__main__":-এর নিচে (পর্ব ২২)।

আপনি যদি এমন একটি library লেখেন যা অন্যরা import করবে, নিয়ম আরও কড়া: library কখনো basicConfig ডাকবে না, নিজে কোনো handler বসাবে না। কারণ library জানে না তাকে কে, কোথায় ব্যবহার করছে — একটি ওয়েব সার্ভার, যেখানে log যায় JSON হয়ে একটি সার্ভিসে? নাকি একটি ছোট স্ক্রিপ্ট? সিদ্ধান্ত application-এর। আরও একটি কারিগরি কারণ: root logger-এ আগে থেকে handler থাকলে basicConfig আর কিছুই করে না (যদি না force=True দেন), তাই library আগে ডাকলে application-এর কনফিগারেশন চুপচাপ উপেক্ষিত হয়। Library শুধু এটুকু করতে পারে:

import logging
logging.getLogger(__name__).addHandler(logging.NullHandler())   # নিজে কিছু ছাপবে না

Logger-এর বংশতালিকা

Logger-এর নামের বিন্দু একটি বংশতালিকা বানায়: app.payment হলো app-এর সন্তান, আর সবার ওপরে root logger. একটি বার্তা যে logger-এ লেখা হয়, সেখান থেকে বাবা-দাদার handler-গুলোর দিকে ওপরে ওঠে — একে বলে propagation. এজন্যই root-এ একটি handler বসালেই সব module-এর বার্তা সেখানে পৌঁছায়। একটি সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ নিয়মও আছে — stepper-এর তৃতীয় ধাপে দেখুন:

log = logging.getLogger("app.payment")
log.info("পেমেন্ট সফল: 300 টাকা")

app.payment-এর নিজের level NOTSET
→ কার্যকর level ধার করে বাবা app থেকে: INFO
→ INFO ≥ INFO, বার্তা পাস

app.payment-এর নিজের handler নেই → ওপরে ওঠা
app-এর FileHandler (level নেই) → লেখা হলো

app.log:
INFO app.payment: পেমেন্ট সফল: 300 টাকা

ওপরে ওঠার সময় root LOGGER-এর level (WARNING)
আর দেখা হয় না!
কিন্তু root-এর HANDLER-এর নিজের level WARNING
→ INFO < WARNING → handler ফেলে দিল

পর্দা: (কিছুই নেই)

log.warning("OTP দুবার ভুল")

app.log:  WARNING app.payment: OTP দুবার ভুল
পর্দা:    WARNING app.payment: OTP দুবার ভুল

logging.getLogger("app").propagate = False

log.warning("OTP দুবার ভুল")
app.log:  WARNING app.payment: OTP দুবার ভুল
পর্দা:    (কিছুই নেই — app-এর পরে যাত্রা থামল)

বাস্তব কাজ — খারাপ সারি লগ করে এগিয়ে যাওয়া

ধরুন একটি স্ক্রিপ্ট ভর্তি পরীক্ষার ফলের একটি ফাইল থেকে শিক্ষার্থীদের GPA আমদানি করে। হাজার সারির মধ্যে কয়েকটিতে GPA খালি বা ভুল লেখা। একটি খারাপ সারির জন্য পুরো আমদানি ক্র্যাশ করা ঠিক নয়, আবার চুপচাপ বাদ দেওয়াও ঠিক নয় (পর্ব ২৪-এর “ভুল গিলে ফেলা”)। সমাধান: খারাপ সারি সারি-নম্বরসহ WARNING-এ লগ করুন, ভালোগুলো নিয়ে এগিয়ে যান, শেষে একটি সারসংক্ষেপ:

import logging
import sys

logging.basicConfig(level=logging.DEBUG, stream=sys.stdout,
                    format="%(levelname)s:%(name)s:%(message)s")
log = logging.getLogger("importer")

rows = ["Rahim,3.75", "Karim,", "Sumi,4.00", "Joy,চার", "Mitu,3.50"]
total, ok = 0.0, 0
for n, row in enumerate(rows, start=1):
    name, _, gpa_text = row.partition(",")
    try:
        gpa = float(gpa_text)
    except ValueError as e:
        log.warning("সারি %d বাদ (%s): %s", n, name, e)
        continue
    log.debug("সারি %d ঠিক: %s=%.2f", n, name, gpa)
    total, ok = total + gpa, ok + 1
log.info("%d-এর মধ্যে %d সারি নেওয়া হলো, গড় GPA %.2f", len(rows), ok, total / ok)

Structured logging আর warnings module — সংক্ষেপে

বড় সিস্টেমে প্রতিদিন লাখ লাখ log লাইন হয়, যা মানুষ নয়, মেশিন খোঁজে: “গত এক ঘণ্টায় অর্ডার 1042-এর সব লাইন দেখাও।” তখন সাধারণ বাক্যের বদলে প্রতিটি লাইন লেখা হয় নির্দিষ্ট ঘরসহ, প্রায়ই JSON হিসেবে — {"level": "INFO", "event": "payment_ok", "order_id": 1042, "amount": 300}. একে বলে structured logging. Standard library-তে extra={"order_id": 1042} দিয়ে বাড়তি ঘর যোগ করা যায় আর নিজের Formatter লিখে JSON বানানো যায়; structlog-এর মতো third-party library এই কাজ সহজ করে।

আর একটি আত্মীয় module: warnings. logging হলো চলমান প্রোগ্রামের ঘটনার খাতা — অপারেটরের জন্য। warnings হলো কোড লেখা প্রোগ্রামারের জন্য সতর্কবার্তা: “আপনি যে ফাংশন ব্যবহার করছেন, তা পরের version-এ বাদ যাবে।” Library লেখকরা লেখেন warnings.warn("old_api() বাদ যাবে, new_api() ব্যবহার করুন", DeprecationWarning, stacklevel=2). একই সতর্কবার্তা একই জায়গা থেকে বারবার এলেও স্বাভাবিকভাবে একবারই দেখায়, আর DeprecationWarning সাধারণত লুকানো থাকে, শুধু আপনার নিজের __main__ কোড থেকে ডাকলে বা টেস্ট চালানোর সময় দেখায়। চাইলে logging.captureWarnings(True) দিয়ে সব warning logging-এর খাতায় পাঠানো যায়।

৯ · AI-এর যুগে — AI-কে দিয়ে ডিবাগ করানো, আর AI-এর ডিবাগ-অভ্যাস যাচাই

AI এখন ডিবাগিংয়ের খুব কাজের সঙ্গী — একটি traceback দেখে কয়েক সেকেন্ডে সম্ভাব্য কারণ বলে দিতে পারে। কিন্তু AI-এর উত্তর ততটাই ভালো, যতটা ভালো আপনার দেওয়া প্রমাণ। “আমার কোড কাজ করছে না” লিখলে সে আন্দাজ করে; পুরো traceback, ছোট একটি পুনরুৎপাদনযোগ্য উদাহরণ (অংশ ৬) আর “কী আশা করেছিলাম, কী পেলাম” দিলে সে যুক্তি দিতে পারে। আর AI-এর নিজের কিছু অভ্যাস আছে, যা চোখে রাখতে হয়:

AI-এর পরামর্শ পেলে — যাচাইয়ের চেকলিস্ট

• প্রস্তাবিত সমাধান বাগের মূল কারণ ঠিক করে, শুধু ক্র্যাশের লাইনে চাপা দেয় না
• কোনো নতুন except Exception: pass বা খালি except: যোগ হয়নি
• Debug-এর জন্য বসানো print আর breakpoint() মুছে ফেলা হয়েছে, বা logging-এ বদলানো হয়েছে
• log ডাকে %s-ধাঁচ; except-এর ভেতরে log.exception; basicConfig শুধু প্রবেশদ্বারে
• কোনো log লাইনে password, PIN, OTP, token বা পুরো request/user object নেই
• AI-কে পাঠানো কোড বা traceback-এও কোনো আসল secret, গ্রাহকের তথ্য বা API key ছিল না
• বাগটির জন্য একটি regression test লেখা হয়েছে, আর আমি নিজে চালিয়ে দেখেছি — আগে ব্যর্থ, এখন পাস