context manager — with-এর ভেতরের কথা

১ · মূল ভাবনা — যা নিয়েছেন, তা ফেরত দিতেই হবে

প্রোগ্রাম অনেক সময় এমন জিনিস ধার নেয়, যা সীমিত বা অন্যদের সাথে ভাগ করে ব্যবহার করতে হয়। এগুলোকে বলে resource বা সম্পদ। কয়েকটি উদাহরণ:

• ফাইল: অপারেটিং সিস্টেম একটি প্রোগ্রামকে একসাথে সীমিত সংখ্যক ফাইল খুলতে দেয়। খোলা ফাইল বন্ধ না করলে লেখা ডেটা ডিস্কে পৌঁছাতে দেরি হয়, আর Windows-এ খোলা ফাইল মোছা বা সরানোও যায় না।
• Lock: কয়েকটি thread একই ডেটা বদলালে একটি lock দিয়ে পালা ঠিক করা হয়। Lock নিয়ে ছেড়ে না দিলে বাকি সব thread চিরকাল অপেক্ষায় থাকে — প্রোগ্রাম আটকে যায়।
• ডেটাবেস transaction: কয়েকটি বদল একসাথে হয় সবগুলো, নয়তো একটিও নয়। শেষে হয় commit (স্থায়ী করা), নয়তো rollback (সব বাতিল করে আগের অবস্থায় ফেরা)। মাঝপথে ফেলে রাখা চলে না।
• সাময়িক বদল: কাজের জন্য অন্য ফোল্ডারে যাওয়া, দশমিকের নির্ভুলতা কিছুক্ষণের জন্য বদলানো, print-এর আউটপুট অন্য জায়গায় পাঠানো — কাজ শেষে আগের অবস্থা ফিরিয়ে আনতেই হবে।

প্রতিটির একই ছাঁচ: আগে (নেওয়া/খোলা/বদলানো) → মাঝে আসল কাজ → পরে (ফেরত/বন্ধ/আগের অবস্থা)। আর আসল বিপদ মাঝের অংশে। কাজের মাঝে একটি exception উঠলে (পর্ব ২৪) Python সাথে সাথে ফাংশন ছেড়ে বেরিয়ে যায় — নিচের “পরে” লাইনটি আর চলে না। return, break বা continue দিয়েও “পরে” অংশ এড়িয়ে যাওয়া সহজ। ফলে তৈরি হয় resource leak: সম্পদ নেওয়া হলো, ফেরত দেওয়া হলো না।

পুরোনো সমাধান: try/finally

পর্ব ২৪-এ দেখেছেন, finally ব্লক সবসময় চলে — সফল হলেও, exception হলেও, return হলেও। তাই with-এর আগে Python-এ সঠিক কোড ছিল এমন:

f = open("sales.csv", encoding="utf-8")   # আগে
try:
    data = f.read()                       # মাঝে — এখানে error হতে পারে
finally:
    f.close()                             # পরে — সবসময় চলবে

কোডটি ঠিক, কিন্তু তিনটি দুর্বলতা আছে। এক, প্রতিবার একই চার লাইনের কাঠামো লিখতে হয়, আর ভুলে যাওয়া সহজ। দুই, open() লাইনটি try-এর বাইরে রাখতে হয় (খোলাই ব্যর্থ হলে বন্ধ করার কিছু নেই) — এই সূক্ষ্মতা অনেকে ভুল করেন। তিন, “কীভাবে বন্ধ করতে হয়” জ্ঞানটি ব্যবহারকারীর কোডে ছড়িয়ে থাকে: ফাইলের জন্য close(), lock-এর জন্য release(), ডেটাবেসের জন্য commit()/rollback(). প্রতিটি ব্যবহারকারীকে প্রতিটির নিয়ম মনে রাখতে হয়।

with statement তৃতীয় সমস্যাটির মূলে আঘাত করে: পরিষ্কারের নিয়মটি থাকে সম্পদের নিজের ভেতরে, ব্যবহারকারীর কোডে নয়। ব্যবহারকারী শুধু বলেন “এই ব্লকের জন্য এটি নাও”, বাকিটা সম্পদ নিজে জানে।

২ · with আসলে কী করে — protocol আর try/finally পাশাপাশি

পর্ব ৩০-এ দেখেছেন, Python-এর অনেক সিনট্যাক্স আসলে কিছু dunder method ডাকে — len(x) ডাকে x.__len__(), for ডাকে __iter__. with-ও তাই। যে object-এ দুটি method আছে, সে-ই context manager. এই দুই method-এর চুক্তিকে বলে context manager protocol:

এবার মূল প্রশ্ন: with ঠিক কোন কোডের সমান? PEP 343 নিজেই এর উত্তর দিয়েছে। একটু সরল করে, বাঁ দিকের দুই লাইন আর ডান দিকের কোড একই কাজ করে:

with Manager() as m:
    কাজ(m)

mgr = Manager()                  # ১. expression হিসাব
m = mgr.__enter__()              # ২. ঢোকা; ফেরত মান → m
ok = True
try:
    কাজ(m)                        # ৩. body
except BaseException as e:
    ok = False
    if not mgr.__exit__(type(e), e, e.__traceback__):
        raise                    # ৪ক. False হলে exception ওপরে
finally:
    if ok:
        mgr.__exit__(None, None, None)   # ৪খ. সফল হলে

এই বিস্তারিত রূপটি থেকে চারটি নিয়ম বেরিয়ে আসে, যেগুলো মুখস্থ নয় — বুঝে রাখার মতো:

1. as পায় __enter__-এর ফেরত মান, object নিজেকে নয়। with open(...) as f-এ f হলো file object, কারণ file-এর __enter__ self ফেরত দেয়। কিন্তু with lock as x-এ x হবে True — lock-এর __enter__ acquire()-এর ফল ফেরত দেয়।
2. ঢোকা ব্যর্থ হলে বেরোনো নেই। ফাইলটিই না থাকলে open() নিজেই FileNotFoundError দেয়; বন্ধ করার কিছু তৈরিই হয়নি।
3. বেরোনোর কাজ একবার, নিশ্চিতভাবে। return, break, continue — সবই finally-এর মতো __exit__ পার হয়ে যায়।
4. exception কী হবে, তা ঠিক করে __exit__-এর ফেরত মান। সত্য-মান (True) হলে চাপা; মিথ্যা-মান (False, None, কিছুই না লেখা) হলে আবার ওঠে।

এবার একটি ছোট context manager-এর পুরো জীবন ধাপে ধাপে দেখুন — প্রথমে সফল পথে, তারপর exception-এর পথে। “পরে” চাপুন:

mgr = Manager()        # __init__ চলে
                       # এখনো কিছু খোলা হয়নি

m = mgr.__enter__()    # প্রস্তুতি: খোলা, lock নেওয়া
                       # এখান থেকে __exit__ নিশ্চিত

কাজ(m)                 # কোনো exception নেই
# শেষ লাইন পর্যন্ত চলল

mgr.__exit__(None, None, None)
# ফেরত মান এখানে অর্থহীন
# with-এর পরের লাইনে যায়

কাজ(m)
  x = 100 / 0          # ZeroDivisionError!
  # body-র বাকি লাইন বাদ

mgr.__exit__(ZeroDivisionError,
             ZeroDivisionError('division by zero'),
             <traceback>)

False / None → exception আবার ওঠে (সাধারণ)
True         → চাপা পড়ে; with-এর পরের লাইন চলে

৩ · নিজের context manager — class দিয়ে

Protocol মাত্র দুটি method, তাই যেকোনো class-কে context manager বানানো যায়। তিনটি বাস্তব উদাহরণ দেখি, ক্রমশ জটিল।

Timer — সময় মেপে attribute-এ রাখা

একটি কোড-অংশ কত সময় নেয়, মাপতে চান। পর্ব ৩৫-এ @timer decorator পুরো ফাংশন মেপেছিল; context manager দিয়ে ফাংশনের ভেতরের যেকোনো অংশ মাপা যায়:

import time

class Timer:
    def __enter__(self):
        self.start = time.perf_counter()
        return self                        # as t → এই object
    def __exit__(self, exc_type, exc, tb):
        self.elapsed = time.perf_counter() - self.start
        return False                       # exception হলে ওপরে যাক

with Timer() as t:
    report = build_monthly_report()
# এখানে t.elapsed পড়ে লগে লিখুন বা তুলনা করুন

তিনটি নকশা-সিদ্ধান্ত লক্ষ করুন। এক, __enter__ self ফেরত দেয়, তাই as t দিয়ে ব্লকের পরেও object-টি হাতে থাকে। দুই, Timer নিজে কিছু ছাপে না; ফল রাখে t.elapsed attribute-এ — কে কীভাবে ব্যবহার করবেন (লগ, টেস্ট, গ্রাফ), সেটা ব্যবহারকারীর সিদ্ধান্ত। তিন, ব্লকে exception হলেও সময় মাপা হয়, আর exception চাপা পড়ে না। পর্ব ২৭-এর time.perf_counter() সময় মাপার সঠিক ঘড়ি।

ChangeDir — কিছুক্ষণের জন্য অন্য ফোল্ডারে

কিছু টুল (পুরোনো script, build tool) ধরে নেয় যে প্রোগ্রাম একটি নির্দিষ্ট ফোল্ডারে চলছে। কাজের জন্য সেখানে যাওয়া আর কাজ শেষে — error হলেও — আগের জায়গায় ফেরা:

import os

class ChangeDir:
    def __init__(self, target):
        self.target = target               # এখানে শুধু মনে রাখা
    def __enter__(self):
        self.old = os.getcwd()             # কোথায় ছিলাম
        os.chdir(self.target)
        return self.target
    def __exit__(self, exc_type, exc, tb):
        os.chdir(self.old)                 # যা-ই ঘটুক, ফিরে যাও

এখানে __exit__ কিছুই ফেরত দেয়নি, মানে None — মিথ্যা-মান, তাই exception ওপরে যাবে। এটাই স্বাভাবিক ধরন। মজার তথ্য: এই কাজটি এত প্রচলিত যে Python 3.11 থেকে স্ট্যান্ডার্ড লাইব্রেরিতে তৈরি contextlib.chdir আছে। তবে মনে রাখবেন, বর্তমান ফোল্ডার পুরো process-এর একটি global state — কয়েকটি thread একসাথে এটি বদলালে একে অপরের ফোল্ডার নষ্ট করবে। তাই নতুন কোডে pathlib দিয়ে পূর্ণ path ব্যবহার করাই ভালো (পর্ব ২৫); chdir রাখুন বাধ্য হলে।

Transaction — ব্যর্থ হলে সব আগের মতো

এবার সবচেয়ে গুরুত্বপূর্ণ ব্যবহার। মোবাইল wallet-এ রহিম করিমকে ৩০০ টাকা পাঠাবেন। কাজ দুই ধাপের: (১) রহিমের হিসাব থেকে কাটা, (২) করিমের হিসাবে জমা। ধাপ ১-এর পরে ধাপ ২ ব্যর্থ হলে কী হবে? টাকা রহিমের কাছ থেকে কাটা গেল, কিন্তু কারও কাছে পৌঁছাল না — হাওয়ায় মিলিয়ে গেল! ঠিক আচরণ হলো ধাপ ১-ও বাতিল করা। এই “সব, নয়তো কিছুই নয়” নিশ্চয়তাকে বলে atomicity.

আসল ডেটাবেসের বদলে একটি dict দিয়ে নকল “ডেটাবেস” বানিয়ে ব্যাপারটি দেখা যাক। __enter__ শুরুর অবস্থার একটি কপি রাখে; __exit__ exception দেখলে সেই কপি ফিরিয়ে আনে। দুটি লেনদেন চলবে — একটি সফল, একটিতে প্রাপকের নামই ভুল। চালানোর আগে শেষ লাইনের আউটপুট অনুমান করুন:

class Transaction:
    def __init__(self, db):
        self.db = db
    def __enter__(self):
        self.snapshot = dict(self.db)       # আগের অবস্থার কপি
        return self.db
    def __exit__(self, exc_type, exc, tb):
        if exc_type is not None:            # body-তে exception হয়েছে
            self.db.clear()
            self.db.update(self.snapshot)   # rollback
            print("rollback:", exc_type.__name__, exc)
        return False                        # exception চাপা নয়

accounts = {"রহিম": 1000, "করিম": 200}
for dst in ["করিম", "সুমি"]:
    try:
        with Transaction(accounts) as db:
            db["রহিম"] -= 300                # ধাপ ১: কাটা
            db[dst] += 300                  # ধাপ ২: জমা
    except KeyError:
        print("ব্যর্থ:", dst, "নামে কোনো অ্যাকাউন্ট নেই")
    print(accounts)

এই নকল transaction আসল ডেটাবেসের তুলনায় খুব সরল: পুরো dict কপি করা বড় ডেটায় চলে না, আর কয়েকজন একসাথে লিখলে কোনো সুরক্ষা নেই। আসল ডেটাবেস (SQLite, PostgreSQL) journal বা log রেখে এই কাজ দক্ষতার সাথে করে। কিন্তু Python-এর দিক থেকে চেহারা একই — অংশ ৬-এ দেখবেন sqlite3 connection ঠিক এভাবেই with-এ commit বা rollback করে।

৪ · @contextmanager — generator দিয়ে সহজ পথ

প্রতিটি context manager-এর জন্য একটি পুরো class — __init__, __enter__, __exit__, মাঝের অবস্থা self-এ রাখা — একটু ভারী লাগে। বিশেষ করে যখন “আগে” আর “পরে” মাত্র এক-দুই লাইন। স্ট্যান্ডার্ড লাইব্রেরির contextlib module এর একটি চমৎকার সমাধান দেয়: @contextmanager decorator (পর্ব ৩৫-এর তালিকায় এর নাম দেখেছিলেন)।

ভাবনাটি পর্ব ৩৪-এর generator থেকে আসে। generator ফাংশন yield-এ থেমে যায় আর পরে ঠিক সেখান থেকে আবার চলে। context manager-এর দরকারও ঠিক এমন একটি “থামা”: আগের কাজ → থামো, ব্লক চলুক → পরের কাজ। তাই নিয়ম সরল:

• yield-এর আগের কোড = __enter__-এর কাজ।
• যা yield করা হয় = as-এর নামে বসে।
• yield-এর পরের কোড = __exit__-এর কাজ — আর একে অবশ্যই finally-এর ভেতরে রাখতে হবে।
• generator ঠিক একবার yield করবে — বেশি বা কম হলে RuntimeError.

from contextlib import contextmanager

@contextmanager
def opened(name):
    print("খোলা", name)          # __enter__-এর কাজ
    try:
        yield name               # as f ← এই মান; এখানে থেমে ব্লক চলে
    finally:
        print("বন্ধ", name)       # __exit__-এর কাজ — error হলেও

with opened("a.csv") as f:
    print("কাজ", f)
print("পরে")

finally কেন বাধ্যতামূলক? কারণ ব্লকে exception হলে @contextmanager সেটি generator-এর ভেতরে, ঠিক yield লাইনে “ছুড়ে” দেয় (generator-এর throw() method দিয়ে)। generator-এর দৃষ্টিতে মনে হয় yield লাইনটিই exception দিয়েছে। finally না থাকলে নিচের পরিষ্কারের লাইন আর চলবে না — পুরো ব্যবস্থার উদ্দেশ্যই নষ্ট। ধাপে ধাপে দেখুন:

1@contextmanager2def opened(name):3    print("খোলা", name)4    try:5        yield name6    finally:7        print("বন্ধ", name)89with opened("a.csv") as f:10    print("কাজ", f)11print("পরে")

বাস্তব উদাহরণ: টাকার হিসাবে সাময়িক নির্ভুলতা

পর্ব ০৭-এ দেখেছেন, টাকার হিসাবে float নয়, Decimal. Decimal-এর হিসাব একটি “context” মেনে চলে — কত অঙ্ক পর্যন্ত নির্ভুলতা (prec, default ২৮), কীভাবে round করা হবে। একটি নির্দিষ্ট হিসাবের জন্য এটি বদলাতে চাইলে global সেটিং বদলানো বিপজ্জনক — অন্য সব হিসাবও বদলে যাবে, আর বদল ফেরাতে ভুলে গেলে বাগ ছড়িয়ে পড়বে। decimal.localcontext() একটি context manager, যা ব্লকের জন্য একটি কপি দেয়, আর বেরোনোর সময় আগেরটি ফিরিয়ে আনে:

from decimal import Decimal, localcontext, ROUND_HALF_UP

price = Decimal("1000") / Decimal("3")       # 333.3333… (২৮ অঙ্ক)

with localcontext(prec=6, rounding=ROUND_HALF_UP):   # Python 3.11+
    per_head = Decimal("1000") / Decimal("3")       # 333.333
# এখানে আবার ২৮ অঙ্কের সাধারণ context

একটি সূক্ষ্মতা: এই context প্রতিটি thread-এর (এবং asyncio-তে প্রতিটি task-এর) জন্য আলাদা, তাই এক জায়গার বদল অন্য thread-এ ঢোকে না। কিছু টাকা আর সেন্ট বা পয়সায় ঠিকঠাক round করতে আসলে quantize() (পর্ব ০৭) বেশি উপযুক্ত; localcontext দরকার হয় যখন পুরো একটি হিসাব-ধারা অন্য নিয়মে চালাতে চান। @contextmanager দিয়ে আপনি নিজেও এমন “সাময়িক বদল, তারপর ফেরত” manager লিখতে পারেন — একটি global সেটিং বদলানো আর finally-তে আগের মান ফেরানো।

৫ · contextlib-এর তৈরি হাতিয়ার

নিজে লেখার আগে দেখে নিন, contextlib-এ হয়তো তৈরিই আছে। সবচেয়ে কাজেরগুলো:

suppress — এবং কেন সাবধান থাকবেন

import os
from contextlib import suppress

with suppress(FileNotFoundError):     # ফাইল না থাকলেও সমস্যা নেই
    os.remove("old_report.tmp")

# সমান: try: os.remove(...)  except FileNotFoundError: pass

এখানে suppress ঠিক ব্যবহার: একটি নির্দিষ্ট, প্রত্যাশিত exception, আর ব্লকে মাত্র একটি লাইন। দুটি ভুল ব্যবহার থেকে সাবধান। এক, suppress(Exception) — এটি প্রায় সবকিছু গিলে ফেলে, বানান ভুল থেকে শুরু করে অনুমতির সমস্যা পর্যন্ত। দুই, ব্লকে অনেক লাইন রাখা — exception হলে ব্লকের বাকি সব লাইন বাদ পড়ে, আর কোনো খবর থাকে না কোন লাইন পর্যন্ত চলেছিল। suppress-এর ব্লক হোক এক লাইনের, আর exception হোক যতটা সম্ভব নির্দিষ্ট।

closing আর nullcontext

কিছু পুরোনো বা তৃতীয় পক্ষের object-এ close() আছে কিন্তু __enter__/__exit__ নেই। with closing(obj) as o: তাদের জন্য বেরোনোর সময় close() ডাকে। আর nullcontext একটি “ফাঁকা” manager — কোডের একই কাঠামো রাখতে, যখন কোনো শর্তে সত্যিকারের manager দরকার নেই:

from contextlib import nullcontext

def save(data, lock=None):
    with lock if lock is not None else nullcontext():
        write_to_disk(data)          # lock থাকলে পাহারায়, না থাকলে সরাসরি

redirect_stdout — print ধরা, টেস্টের জন্য দারুণ

ধরুন একটি পুরোনো ফাংশন রসিদ print করে, আর আপনি টেস্ট লিখতে চান যে রসিদে ঠিক কী লেখা হলো। stdout-কে কিছুক্ষণের জন্য একটি io.StringIO-তে পাঠানো যায় — একটি নকল ফাইল, যা লেখাগুলো মেমরিতে জমায়। ব্লক শেষে print আবার আগের মতো স্ক্রিনে যায়। (pytest-এর capsys একই কাজ আরও সুবিধাজনকভাবে করে — পর্ব ৩৯।)

ExitStack — কয়টি resource, আগে জানা নেই

with open("a.csv") as a, open("b.csv") as b: চলে যখন ফাইলের সংখ্যা কোড লেখার সময়ই জানা। কিন্তু ব্যবহারকারী যদি ৩টি বা ৩০টি জেলার CSV দেন? লুপের ভেতরে with দিলে প্রতিটি ফাইল পরের ফাইল খোলার আগেই বন্ধ হয়ে যাবে — অথচ সবগুলো একসাথে খোলা দরকার (যেমন পাশাপাশি মিলিয়ে পড়তে)। ExitStack হলো একটি “context manager-এর স্তূপ”: stack.enter_context(cm) প্রতিটি manager-এ ঢোকে আর তার __exit__ স্তূপে তুলে রাখে। ExitStack-এর ব্লক শেষ হলে স্তূপের ওপর থেকে — অর্থাৎ খোলার উল্টো ক্রমে — সবগুলো বন্ধ হয়।

1with ExitStack() as stack:2    files = [stack.enter_context(open(p))3             for p in paths]4    merge(files)5# ব্লক শেষ — স্তূপ খালি হচ্ছে

এবার দ্বিতীয় runnable প্রোগ্রাম, যেখানে দুটি হাতিয়ার একসাথে: redirect_stdout দিয়ে একটি ফাংশনের print ধরা, আর ExitStack দিয়ে নিজের লেখা @contextmanager manager তিনবার খোলা। আসল ফাইলের বদলে manager-টি শুধু একটি তালিকায় লিখে রাখে কখন খোলা আর কখন বন্ধ হলো — যাতে ক্রমটি চোখে দেখা যায়:

import io
from contextlib import contextmanager, redirect_stdout, ExitStack
@contextmanager
def opened(name, log):
    log.append(f"খোলা {name}")           # __enter__-এর কাজ
    try:
        yield name.upper()
    finally:
        log.append(f"বন্ধ {name}")       # __exit__-এর কাজ

def receipt(total):
    print("মোট:", total, "টাকা")
buf, log = io.StringIO(), []
with redirect_stdout(buf):
    receipt(550)                         # স্ক্রিনে কিছু আসবে না
with ExitStack() as stack:
    files = [stack.enter_context(opened(n, log)) for n in ("a.csv", "b.csv", "c.csv")]
    log.append(f"কাজ {files}")
print(*log, sep="\n")
print("ধরা লেখা:", repr(buf.getvalue()))

৬ · একসাথে কয়েকটি manager, আর যেগুলো আপনি আগেই ব্যবহার করছেন

এক with-এ কয়েকটি

একটি ফাইল পড়ে আরেকটিতে লিখতে নেস্ট করা দুটি with লাগে না — কমা দিয়ে এক লাইনে লেখা যায়, আর এটি হুবহু নেস্ট করার সমান: বাঁ থেকে ডানে ঢোকা, ডান থেকে বাঁয়ে বেরোনো। লম্বা হলে Python 3.10 থেকে বন্ধনী দিয়ে কয়েক লাইনে ভাঙা যায়:

with open("in.csv", encoding="utf-8") as src, open("out.csv", "w", encoding="utf-8") as dst:
    dst.write(src.read())

with (                                          # Python 3.10+
    open("in.csv", encoding="utf-8") as src,
    open("out.csv", "w", encoding="utf-8") as dst,
):
    dst.write(src.read())

দ্বিতীয় open ব্যর্থ হলে (যেমন লেখার অনুমতি নেই) প্রথম ফাইলটি ঠিকই বন্ধ হয় — কারণ প্রথমটির __enter__ ইতিমধ্যে সফল হয়েছিল।

চেনা context manager — ভেতরে কী হয়

sqlite3-এর বিখ্যাত চমক — commit করে, বন্ধ করে না

অনেকেই ধরে নেন with sqlite3.connect("bank.db") as conn: শেষে connection বন্ধ হয়, যেমন ফাইলে হয়। হয় না। SQLite connection-এর __exit__ শুধু transaction শেষ করে: ব্লক সফল হলে commit, exception হলে rollback. connection খোলাই থাকে — পরের with conn:-এ আবার ব্যবহার করা যায়। এটি নকশা অনুযায়ীই; Python-এর ডকুমেন্টেশনে স্পষ্ট লেখা আছে। কিন্তু প্রত্যাশার উল্টো বলে এটি একটি পরিচিত ফাঁদ: লুপে বারবার sqlite3.connect() ডেকে with-এ রাখলে একগাদা খোলা connection জমতে পারে।

import sqlite3
from contextlib import closing

with closing(sqlite3.connect("bank.db")) as conn:   # বাইরের: বন্ধ করা
    with conn:                                        # ভেতরের: transaction
        conn.execute("UPDATE acc SET bal = bal - 300 WHERE name = ?", ("রহিম",))
        conn.execute("UPDATE acc SET bal = bal + 300 WHERE name = ?", ("করিম",))
    # এখানে commit হয়ে গেছে (বা exception হলে rollback)
# এখানে connection বন্ধ

দুই স্তরের এই কাঠামোটি মনে রাখুন: বাইরের closing সম্পদের জীবন সামলায়, ভেতরের with conn একেকটি transaction. অংশ ৩-এর নকল Transaction যা করেছিল, এখানে আসল ডেটাবেস তা-ই করছে — দ্বিতীয় UPDATE ব্যর্থ হলে প্রথমটিও বাতিল। (? চিহ্ন হলো পর্ব ২৭-এর parameterized query, SQL injection থেকে বাঁচতে। Python 3.12-এ connection-এ নতুন autocommit সেটিং এসেছে, যা transaction-এর আচরণ আরও স্পষ্টভাবে ঠিক করতে দেয়।)

TemporaryDirectory আর async with-এর ঝলক

টেস্ট বা একবারের প্রক্রিয়াকরণের জন্য অস্থায়ী ফোল্ডার দরকার হলে with tempfile.TemporaryDirectory() as tmp: — ব্লক শেষে ফোল্ডারটি ভেতরের সব ফাইলসহ মুছে যায়, কোনো আবর্জনা পড়ে থাকে না। আর পর্ব ৪২-এ asyncio শিখলে দেখবেন async with — একই ধারণা, কিন্তু ঢোকা আর বেরোনোর কাজ নিজেই অপেক্ষা করতে পারে (যেমন নেটওয়ার্ক connection বন্ধ করতে সময় লাগে)। সেখানে method দুটির নাম __aenter__ আর __aexit__, আর contextlib-এ আছে @asynccontextmanager ও AsyncExitStack.

৭ · C++-এর RAII বনাম Python-এর with — কেন __del__-এ ভরসা নয়

C++-এ এই সমস্যার সমাধান আলাদা, আর খুব মার্জিত। একটি object scope থেকে বেরোলে — স্বাভাবিকভাবে বা exception-এ — তার destructor নিশ্চিতভাবে, ঠিক সেই মুহূর্তে চলে। তাই সম্পদকে একটি object-এর জীবনের সাথে বেঁধে দেওয়া হয়: constructor-এ নেওয়া, destructor-এ ফেরত। এই নকশার নাম RAII (Resource Acquisition Is Initialization). এর ফলে C++-এ “বন্ধ করো” লিখতেই হয় না; ফাইল-object scope ছাড়লেই বন্ধ।

Python-এ কি একই কাজ __del__ দিয়ে করা যায়? __del__ হলো সেই method, যা object মেমরি থেকে মোছার আগে চলে। শুনতে destructor-এর মতো, কিন্তু একটি মৌলিক পার্থক্য আছে: Python কখনো প্রতিশ্রুতি দেয় না object ঠিক কখন মুছবে. কারণগুলো:

• CPython-এ reference counting প্রায় সঙ্গে সঙ্গে মোছে — শেষ নামটি চলে গেলে। কিন্তু এটি CPython-এর বাস্তবায়নের খুঁটিনাটি, ভাষার নিয়ম নয়। PyPy-র মতো অন্য Python-এ garbage collector চলে নিজের সময়ে — হয়তো অনেক পরে।
• Reference cycle: দুটি object একে অপরকে দেখালে count শূন্য হয় না; cycle-খোঁজা collector কখন চলবে, তা অনিশ্চিত।
• একটি লুকানো নাম যথেষ্ট: traceback object, একটি cache, বা ডিবাগারের একটি রেফারেন্স object-টিকে জীবিত রাখতে পারে — আপনি টেরও পাবেন না।
• Interpreter বন্ধের সময়: প্রোগ্রাম শেষের সময় module-গুলো ভাঙা হতে থাকে; __del__ হয়তো চলবেই না, বা চললেও যে module ব্যবহার করতে চায় সেটি আর নেই।
• __del__-এর exception হারিয়ে যায়: সেখানে error হলে Python শুধু stderr-এ “Exception ignored in…” লেখে; ডাকার কেউ নেই যে ধরবে।

তাই Python-এর পথ হলো deterministic cleanup স্পষ্টভাবে চাওয়া: with. RAII-তে পরিষ্কার নিশ্চিত করে object-এর জীবনকাল; Python-এ নিশ্চিত করে একটি ব্লক. পার্থক্যটি দৃশ্যমানতায়ও: C++-এ ধ্বংস হয় নিঃশব্দে, scope-এর শেষ বন্ধনীতে; Python-এ with লাইনটি চোখের সামনে বলে দেয় “এখানে একটি সম্পদ নেওয়া হলো, ব্লক শেষে ফেরত যাবে”. খোলা ফাইল with ছাড়া হারিয়ে গেলে Python একটি ResourceWarning দিতে পারে (default-এ লুকানো; python -W default বা development mode-এ দেখা যায়) — এটি ভুলের সংকেত, সমাধান নয়। আর একান্তই object-এর সাথে কোনো শেষ-পরিষ্কার বাঁধতে হলে __del__-এর চেয়ে weakref.finalize নিরাপদ বিকল্প।

৮ · AI-এর যুগে — AI-এর লেখা পরিষ্কারের কোড যাচাই করা

সম্পদ-সংক্রান্ত বাগের বৈশিষ্ট্য হলো, ছোট পরীক্ষায় এরা দেখা দেয় না। একটি ফাইল বন্ধ না করলে আপনার ল্যাপটপে কিছুই হয় না; সার্ভারে দশ হাজার অনুরোধের পরে আসে “Too many open files”. একটি lock ছাড়তে ভুলে গেলে প্রোগ্রাম আটকে যায় শুধু তখন, যখন দুটি thread একসাথে আসে — হয়তো মাসে একবার। AI-এর লেখা কোড প্রথম পরীক্ষায় চলে, তাই এই ভুলগুলো চোখ এড়িয়ে যায়। বারবার দেখা যায় এমন ভুল:

AI-এর লেখা কোড পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি open(, .acquire(), connect( খুঁজে দেখেছি — সবই with-এর ভেতরে, বা ExitStack-এ
• প্রতিটি __exit__-এর ফেরত মান পড়েছি; True থাকলে সেটি শুধু একটি নির্দিষ্ট exception type-এর জন্য
• প্রতিটি @contextmanager-এ ঠিক একটি yield, আর তার পরের পরিষ্কার finally-এর ভেতরে
• body-তে ইচ্ছা করে একটি exception তুলে দেখেছি: পরিষ্কার হয়েছে আর exception ওপরে এসেছে
• কোথাও __del__ নেই, আর suppress থাকলে তার exception নির্দিষ্ট ও ব্লক এক লাইনের
• ডেটাবেসে: transaction (commit/rollback) আর connection বন্ধ — দুটি আলাদাভাবে নিশ্চিত