باز کردن و بستن دستی یک فایل یا مدیریت اتصالات پایگاه داده، شبیه به روشن نگه داشتن چراغ‌های یک خانه خالی است؛ انرژی سیستم شما را هدر می‌دهد و در طولانی‌مدت به زیرساخت‌ها آسیب می‌زند.

بسیاری از برنامه‌نویسان بارها با خطای فراموش کردن بستن فایل‌ها یا قطع نشدن اتصالات شبکه دست‌وپنجه نرم کرده‌اند؛ خطاهایی که پیدا کردن آن‌ها در پروژه‌های بزرگ شبیه به پیدا کردن سوزن در انبار کاه است.

پایتون برای این چالش سنتی، یک راهکار بومی، امن و فوق‌العاده ظریف به نام مدیریت هوشمند منابع (Context Managers) ارائه می‌دهد که با ساختار متمایز دستور with شناخته می‌شود.

در این درس یاد می‌گیرید که چگونه با این ابزار قدرتمند، فرآیندهای حساسِ تخصیص و آزادسازی منابع را به خود پایتون بسپارید. این قابلیت کدهای طولانی و پر از بلوک‌های تکراری try/finally را به کدهایی خوانا، خلاصه و کاملاً پایتونیک تبدیل می‌کند.

یادگیری این مبحث به شما کمک می‌کند تا برنامه‌هایی بنویسید که حتی در صورت رخ دادن بدترین خطاهای غیرمنتظره، منابع سیستم را به شکلی کاملاً امن و خودکار پاک‌سازی کنند و پایداری نرم‌افزار شما را در محیط عملیاتی تضمین نمایند.

چرا مدیریت سنتی منابع خطرناک است؟ (چالش بلوک‌های try/finally)

مدیریت منابع در مهندسی نرم‌افزار به معنای کنترل چرخه حیات ابزارهایی است که ظرفیت محدودی در سیستم دارند. فایل‌های متنی، اتصالات شبکه (Sockets)، ارتباطات پایگاه داده و قفل‌های سیستم، همگی جزو منابع محدود به شمار می‌روند.

بزرگ‌ترین چالش در مواجهه با این منابع، اطمینان از آزادسازی قطعی آن‌ها پس از اتمام کار است. سیستم‌عامل برای باز نگه‌داشتن هر فایل یا هر اتصال دیتابیس، بخشی از حافظه و پردازش خود را درگیر می‌کند.

اگر برنامه‌نویس فراموش کند این اتصالات را ببندد، پدیده‌ای به نام نشت منابع (Resource Leak) رخ می‌دهد که در طولانی‌مدت می‌تواند سرور را کاملاً فلج کند.

به طور سنتی، برنامه‌نویسان برای جلوگیری از این بحران، از ساختار شرطی try/finally استفاده می‌کنند. ایده پشت این روش ساده است: کدهای اصلی را در بلوک try بنویسید و عملیات بستن منبع را در بلوک finally قرار دهید تا مطمئن شوید حتی در صورت بروز خطا، کد پاک‌سازی اجرا می‌شود. به این نمونه کلاسیک نگاه کنید:

file = open("analytics_report.txt", "w")
try:
    file.write("Processing big data...")
    # فرض کنید اینجا یک خطای منطقی یا محاسباتی رخ می‌دهد
    result = 1 / 0 
finally:
    file.close()
    print("فایل با موفقیت بسته شد.")

این ساختار در ظاهر درست کار می‌کند، اما وقتی ابعاد پروژه بزرگ می‌شود، مدیریت سنتی به شدت خطرناک و آسیب‌رسان خواهد بود. اولین چالش بزرگ، ایجاد کدهای تکراری و به اصطلاح فرسودگی ساختار (Boilerplate Code) است.

اگر در یک متد مجبور باشید به طور هم‌زمان سه فایل مختلف و دو اتصال دیتابیس را مدیریت کنید، کدهای شما در هرمی از بلوک‌های try/finally تو در تو غرق می‌شوند. این وضعیت خوانایی برنامه را به شدت کاهش می‌دهد و فضا را برای خطاهای انسانی باز می‌کند.

خطای پنهان و بسیار خطرناک‌تر زمانی رخ می‌دهد که خودِ فرآیندِ باز کردن منبع یا کدهای داخل بلوک finally با خطا مواجه شوند. به این سناریو دقت کنید:

try:
    # اگر فایل اصلاً وجود نداشته باشد یا دسترسی مدیریت محدود باشد
    file = open("missing_config.json", "r") 
    data = file.read()
finally:
    # چون فایل باز نشده، متغیر خطای NameError یا AttributeError می‌دهد
    file.close()

در این وضعیت، خطای اصلی (عدم وجود فایل) در پشت خطای ثانویه (که در بلوک finally رخ داده) پنهان می‌شود. این پدیده عیب‌یابی و خواندن لاگ‌های سیستم را در محیط عملیاتی به یک کابوس تبدیل می‌کند؛ زیرا خطایی که در خروجی می‌بینید، علت اصلی سقوط برنامه نیست. مدیریت سنتی ابزارها تعهد بالایی از برنامه‌نویس می‌طلبد و کوچک‌ترین حواس‌پرتی در چیدمان این بلوک‌ها، پایداری کل نرم‌افزار را به خطر می‌اندازد.

مفهوم پروتکل مدیریت بافت (Context Manager Protocol) و پشت پرده دستور with

پروتکل مدیریت بافت (Context Manager Protocol) مجموعه‌ای از قوانین و قراردادها در ساختار درونی پایتون است که به اشیا اجازه می‌دهد چرخه حیات خودشان را مدیریت کنند. پایتون برای اجرای این فرآیند به کلمات کلیدی عجیب یا ابزارهای پیچیده متوسل نمی‌شود.

این زبان از متدهای جادویی (Dunder Methods) استفاده می‌کند تا رفتار اشیا را در زمان ورود و خروج به یک محدوده خاص مشخص کند. پروتکل مدیریت بافت به طور دقیق بر پایه دو متد جادویی __enter__ و __exit__ بنا شده است. هر کلاسی که این دو متد را در ساختار خود پیاده‌سازی کند، به یک مدیریت‌کننده بافت تبدیل می‌شود و صلاحیت حضور در دستور with را پیدا می‌کند.

دستور with در ظاهر یک ابزار ساده برای خلاصه کردن کدها به نظر می‌رسد، اما در پشت پرده، مدیریت کامل امنیت و خطایابی برنامه را به دست می‌گیرد. وقتی شما کدی را به صورت زیر می‌نویسید:

with open("data.csv", "r") as file:
    content = file.read()

پایتون در پشت صحنه یک مکانیزم دقیق را به اجرا درمی‌آورد. مفسر پایتون در اولین قدم، عبارت مقابل دستور with را ارزیابی می‌کند تا شیء مدیریت‌کننده بافت را به دست آورد. سپس متد __enter__ آن شیء را فراخوانی می‌کند. وظیفه این متد، آماده‌سازی منابع، باز کردن فایل یا برقراری اتصال دیتابیس است. خروجی متد __enter__ هر چه که باشد، مستقیماً به متغیری اختصاص داده می‌شود که جلوی کلمه کلیدی as نوشته‌اید (در اینجا متغیر file).

پس از تخصیص منابع، کدهای داخل بلوک with شروع به اجرا می‌کنند. بخش حیاتی داستان زمانی آغاز می‌شود که اجرای کدهای این بلوک به پایان برسد، یا اینکه برنامه در میان راه با یک خطای ناگهانی متوقف شود. پایتون در هر دو حالت، متد __exit__ را فراخوانی می‌کند. این متد سه آرگومان مهم به نام‌های نوع خطا (Exception Type)، مقدار خطا (Exception Value) و تریس‌بک (Traceback) را دریافت می‌کند.

اگر کدهای داخل بلوک بدون هیچ مشکلی اجرا شده باشند، این سه آرگومان مقدار None خواهند داشت و متد __exit__ منبع را به آرامی می‌بندد.

اما اگر خطایی رخ داده باشد، متد __exit__ اطلاعات کامل خطا را دریافت می‌کند؛ این متد می‌تواند تصمیم بگیرد که خطا را مدیریت و مخفی کند (با بازگرداندن مقدار True) یا اجازه دهد خطا به لایه‌های بالاتر برنامه پرتاب شود تا سیستم متوقف گردد. دستور with با این ساختار هوشمندانه تضمین می‌کند که کدهای پاک‌سازی پروژه تحت هر شرایطی بدون خطا اجرا شوند.

متدهای جادویی __enter__ و __exit__؛ معماری داخلی ابزار

ساختار داخلی مدیریت بافت در پایتون مستقیماً توسط دو متد جادویی __enter__ و __exit__ هدایت می‌شود. وقتی یک شیء را در مقابل دستور with قرار می‌دهید، پایتون فوراً به سراغ این دو متد می‌رود تا پروتکل مدیریت منابع را پیاده‌سازی کند. شناخت دقیق رفتار و ورودی‌های این دو متد، کلید اصلی درک معماری داخلی این ابزار پایتونیک است.

متد __enter__ مسئول راه‌اندازی و تخصیص منابع است. این متد هیچ آرگومانی به جز self دریافت نمی‌کند. مفسر پایتون به محض ورود به بلاک with، این متد را اجرا می‌کند. مقدار بازگشتی (Return Value) این متد، همان چیزی است که پس از کلمه کلیدی as در اختیار برنامه‌نویس قرار می‌گیرد.

یک اشتباه رایج در میان توسعه‌دهندگان تازه کار این است که تصور می‌کنند متد __enter__ باید حتماً خودِ شیء اصلی (یعنی self) را برگرداند. پایتون هیچ اجباری در این زمینه ندارد. این متد می‌تواند یک اتصال پایگاه داده، یک آبجکت فایل یا هر داده دیگری را که برای کار در داخل بلاک نیاز دارید، برگرداند.

class ResourceConnector:
    def __enter__(self):
        print("اتصال به منبع برقرار شد.")
        return "Target Object"  # این مقدار به متغیر جلوی as منتقل می‌شود

متد __exit__ مسئولیت بسیار سنگین‌تری بر عهده دارد و مدیریت فرآیند خروج و پاک‌سازی منابع را کنترل می‌کند. این متد بر خلاف متد ورود، چهار آرگومان ورودی دریافت می‌کند: self و سه پارامتر تخصصی برای مدیریت خطاهایی که ممکن است در طول اجرای بلاک رخ دهند. ساختار دقیق این متد به شکل زیر تعریف می‌شود:

def __exit__(self, exc_type, exc_value, traceback):
    # کدهای مربوط به بستن منبع

بررسی رفتار این سه پارامتر به شما کمک می‌کند تا کنترل کاملی روی خطاهای برنامه داشته باشید:

پارامتر exc_type: نوع کلاس استثنای رخ‌داده را مشخص می‌کند (مثلاً ZeroDivisionError یا FileNotFoundError).

پارامتر exc_value: نمونه واقعی (Instance) از خطا را که حاوی پیغام خطاست در خود نگه می‌دارد.

پارامتر traceback: شیئی شامل جزئیات دقیق و پشته خطای رخ‌داده است که نشان می‌دهد خطا در کدام خط و کدام تابع اتفاق افتاده است.

اگر کدهای داخل بلاک with بدون هیچ مشکلی اجرا شوند، هر سه پارامتر بالا با مقدار None به متد __exit__ فرستاده می‌شوند. اما اگر خطایی در بلاک رخ دهد، پایتون بلافاصله اجرای کدهای داخلی را متوقف کرده، سه آرگومان مربوط به خطا را پر می‌کند و متد __exit__ را فرا می‌خواند.

خروجی متد __exit__ مشخص می‌کند که سرنوشت خطا چه خواهد شد. این متد باید یک مقدار بولین (Boolean) برگرداند. اگر این متد مقدار True را بازگرداند، به این معنی است که خطا توسط مدیریت بافت شناسایی و مهار شده است؛ در نتیجه پایتون خطا را نادیده می‌گیرد و برنامه بدون سقوط به کار خود ادامه می‌دهد. اما اگر متد مقدار False (یا None) برگرداند، پایتون خطا را به لایه‌های بالاتر پرتاب می‌کند تا سیستم متوقف شود. این مکانیزم هوشمند، پایه و اساس امنیت منابع در کدهای پایتونیک است.

پیاده‌سازی یک Context Manager اختصاصی بر پایه کلاس

ساخت یک مدیریت بافت اختصاصی با استفاده از کلاس‌ها، به شما اجازه می‌دهد کنترل کاملی روی چرخه حیات منابع پیچیده پروژه داشته باشید. برای این کار، کافی است کلاسی طراحی کنید که دو متد جادویی __enter__ و __exit__ را بر اساس پروتکل پایتون پیاده‌سازی کند. این روش زمانی بیشترین ارزش را دارد که می‌خواهید وضعیت‌های پیشرفته یا داده‌های متوالی را در طول اجرای بلاک ذخیره و مدیریت کنید.

برای درک بهتر، سناریوی مدیریت اتصال به یک پایگاه داده فرضی را در نظر بگیرید. کلاس زیر، فرآیند برقراری ارتباط، تخصیص شیء عملیاتی و قطع خودکار اتصال را حتی در صورت بروز خطا شبیه‌سازی می‌کند:

class DatabaseConnection:
    def __init__(self, db_name: str):
        self.db_name = db_name
        self.connection = None

    def __enter__(self):
        print(f"در حال برقراری ارتباط با پایگاه داده {self.db_name}...")
        # شبیه‌سازی ساخت آبجکت اتصال
        self.connection = f"ConnectionObject_to_{self.db_name}"
        return self.connection

    def __exit__(self, exc_type, exc_val, exc_tb):
        print(f"در حال بستن اتصال پایگاه داده {self.db_name}...")
        self.connection = None
        
        if exc_type is not None:
            print(f"یک خطا از نوع {exc_type.__name__} با پیام [{exc_val}] رخ داد.")
            # بازگرداندن False اجازه می‌دهد خطا به لایه‌های بالاتر برود
            return False 
        
        print("اتصال بدون هیچ خطایی و به طور امن بسته شد.")
        return True

نحوه استفاده از این کلاس اختصاصی در بدنه برنامه به شکل زیر خواهد بود:

# سناریوی اول: اجرای موفق بدون خطا
with DatabaseConnection(db_name="users_db") as db:
    print(f"اجرای کوئری روی: {db}")

print("-" * 30)

# سناریوی دوم: بروز خطا در حین اجرای بلاک
try:
    with DatabaseConnection(db_name="orders_db") as db:
        print(f"اجرای کوئری روی: {db}")
        # ایجاد یک خطای فرضی
        raise ValueError("اطلاعات سفارش ناقص است!")
except ValueError:
    print("خطا در خارج از بلاک with مدیریت شد.")

در سناریوی اول، متد __enter__ نام اتصال را برمی‌گرداند و به متغیر db متصل می‌کند. پس از چاپ پیام، متد __exit__ با مقادیر None اجرا شده و کار به پایان می‌رسد.

در سناریوی دوم، به محض پرتاب خطای ValueError، پایتون فوراً کدهای داخل بلاک را متوقف کرده و متد __exit__ را همراه با جزئیات دقیق خطا فرا می‌خواند. اتصال دیتابیس بسته‌شده و چون مقدار False برگشت داده شده است، خطا بالا می‌رود تا در بلوک try/except بیرونی مدیریت شود.

طراحی مدیریت بافت بر پایه کلاس، ابزاری قدرتمند برای جداسازی منطق پاک‌سازی از منطق تجاری برنامه است. این ساختار تضمین می‌کند که کدهای فرعی و تکراری مربوط به نگهداری منابع، هرگز ظاهر کدهای اصلی پروژه شما را کثیف و نامفهوم نکنند.

استفاده از دکوراتور contextmanager در ماژول contextlib (روش پایتونیک و سریع)

طراحی یک کلاس کامل با متدهای جادویی ورود و خروج، ساختاری محکم و قابل اعتماد به ما می‌دهد. با این حال، گاهی اوقات برای کارهای کوچک و سریع، نوشتن یک کلاس جدید با کلی کدهای اضافه (Boilerplate) چندان پایتونیک به نظر نمی‌رسد. پایتون برای این وضعیت یک راهکار فوق‌العاده سریع و ظریف در ماژول درونی contextlib قرار داده است: دکوراتور contextmanager.

این ابزار به شما اجازه می‌دهد یک تابع ژنراتور (Generator) ساده را با کمک کلمه کلیدی yield مستقیم به یک مدیریت‌کننده بافت کامل تبدیل کنید. در این روش، تمام کدهای قبل از yield نقش متد جادویی __enter__ را بازی می‌کنند و کدهای بعد از آن، همان کارهای متد __exit__ را انجام می‌دهند.

به این نمونه پیاده‌سازی برای مدیریت زمان‌سنجی اجرای کدها نگاه کنید:

from contextlib import contextmanager
import time

@contextmanager
def execution_timer(label: str):
    start_time = time.perf_counter()
    print(f"--- شروع فرآیند: {label} ---")
    try:
        # کدهای داخل بلاک with اینجا اجرا می‌شوند
        yield
    finally:
        # کدهای پاک‌سازی و خروج
        end_time = time.perf_counter()
        duration = end_time - start_time
        print(f"--- پایان فرآیند: {label} | زمان مصرف‌شده: {duration:.4f} ثانیه ---")

نحوه استفاده از این تابع در برنامه به این صورت است:

with execution_timer("محاسبه فاکتوریل اعداد بزرگ"):
    result = 1
    for i in range(1, 50000):
        result *= i

وقتی مفسر پایتون وارد بلاک with می‌شود، تابع را تا رسیدن به عبارت yield اجرا می‌کند. در این لحظه کنترل برنامه به کدهای داخل بلاک منتقل می‌شود. پس از اتمام کدهای بلاک، پایتون دوباره به سراغ تابع می‌آید و کدهای بعد از yield را که در بلوک finally قرار دارند، اجرا می‌کند.

بلوک try/finally در اینجا نقشی حیاتی دارد. اگر کدهای داخل بلاک with با خطایی مواجه شوند، آن خطا در محل عبور yield پرتاب می‌شود. اگر این عبارت را درون try/finally نگذارید، کدهای بخش خروج هرگز اجرا نمی‌شوند و منابع سیستم معلق می‌مانند.

دکوراتور contextmanager حجم کدهای شما را به شدت کاهش می‌دهد و خوانایی برنامه را بالا می‌برد. این دکوراتور بهترین انتخاب برای ساخت ابزارهای موقت، لاگرها و فرآیندهای پاک‌سازی سریع در پروژه‌های پایتون است.

مدیریت هم‌زمان چند منبع در یک دستور with

گاهی اوقات در توسعه یک نرم‌افزار، اجرای صحیح برنامه به مدیریت هم‌زمان دو یا چند منبع مختلف وابسته است. کپی کردن محتویات یک فایل به فایل دیگر یا خواندن تنظیمات از یک منبع و اعمال آن روی یک اتصال شبکه، نمونه‌های ملموسی از این نیاز هستند. پایتون برای جلوگیری از نوشتن دستورات with تو در تو و حفظ آراستگی ظاهر کد، امکان مدیریت هم‌زمان چند منبع را در یک خط فراهم کرده است.

برنامه‌نویسان در نسخه‌های قدیمی‌تر پایتون مجبور بودند برای مدیریت دو فایل، ساختاری شبیه به این بنویسند:

# رویکرد قدیمی و تو در تو
with open("source.txt", "r") as source_file:
    with open("destination.txt", "w") as dest_file:
        content = source_file.read()
        dest_file.write(content)

این ساختار اگرچه درست کار می‌کند، اما با افزایش تعداد منابع، تورفتگی‌های کد (Indentation) افزایش یافته و خوانایی برنامه را تحت تاثیر قرار می‌دهد. پایتون این چالش را با اجازه دادن به درج چند مدیریت‌کننده بافت در یک دستور with واحد و تفکیک آن‌ها به کمک کاما (,) حل کرده است:

# رویکرد تمیز و هم‌زمان در یک خط
with open("source.txt", "r") as source_file, open("destination.txt", "w") as dest_file:
    content = source_file.read()
    dest_file.write(content)

پشت صحنه این دستور تفاوت خاصی با ساختار تو در تو ندارد. مفسر پایتون منابع را به ترتیب از چپ به راست باز می‌کند؛ یعنی ابتدا متد __enter__ فایل اول و سپس متد __enter__ فایل دوم اجرا می‌شود. فرآیند بسته شدن منابع و اجرای متدهای __exit__ دقیقاً برعکس، یعنی از راست به چپ رخ می‌دهد تا پایداری منابع حفظ شود.

چالش جدی زمانی رخ می‌دهد که تعداد این منابع زیاد باشد و طول خط از استاندارد ۷۹ کاراکتریِ PEP 8 فراتر رود. پایتون از نسخه ۳.۱۰ به بعد با پشتیبانی از پرانتز در دستور with، ظریف‌ترین راهکار پایتونیک را برای این موضوع ارائه داد. شما می‌توانید منابع را درون یک پرانتز قرار داده و آن‌ها را در خطوط مجزا بنویسید:

# نگارش مدرن و پایتونیک برای منابع متعدد (پایتون ۳.۱۰ به بالا)
with (
    open("source.txt", "r") as source,
    open("backup.txt", "w") as backup,
    open("log.txt", "a") as log_file
):
    content = source.read()
    backup.write(content)
    log_file.write("انتقال داده‌ها با موفقیت انجام شد.")

این شیوه نگارش توازن کاملی میان امنیت منابع، رعایت استانداردهای ظاهری کد و خوانایی نرم‌افزار ایجاد می‌کند. خطایابی در این ساختار بسیار دقیق است؛ اگر در حین کار با هر کدام از این منابع خطایی رخ دهد، پایتون متد __exit__ تمام منابعی را که تا آن لحظه با موفقیت باز شده بودند، فراخوانی می‌کند تا هیچ اتصالی در حافظه سرور معلق باقی نماند.

جمع‌بندی و سناریوهای واقعی استفاده از Context Managers در پروژه (فایل، دیتابیس، قفل‌های چندنخی)

مدیریت هوشمند منابع با دستور with، فراتر از یک ابزار ساده برای بستن فایل‌هاست. این قابلیت در پروژه‌های بزرگ پایتون، پایداری سیستم را در برابر نشت حافظه و قفل شدن منابع تضمین می‌کند. برای درک عمیق‌تر، بررسی سه سناریوی واقعی و کاربردی در پروژه‌های صنعتی، جایگاه اصلی این ابزار را در معماری نرم‌افزار روشن می‌کند.

۱. مدیریت فایل‌های بزرگ و گزارش‌گیری ایمن

در سیستم‌های مالی یا تحلیل داده، پردازش خط به خط فایل‌های سنگین متداول است. اگر در زمان خواندن یک فایل متنی با حجم بالا، خطایی در پردازش داده‌ها رخ دهد، باز ماندن فایل جریان حافظه سرور را مخدوش می‌کند.

class SafeReportProcessor:
    def __init__(self, file_path: str):
        self.file_path = file_path

    def __enter__(self):
        self.file = open(self.file_path, "r", encoding="utf-8")
        return self.file

    def __exit__(self, exc_type, exc_val, exc_tb):
        if self.file:
            self.file.close()
        if exc_type:
            print(f"پردازش فایل با خطا مواجه شد: {exc_val}")
            return False  # اجازه انتشار خطا به لایه‌های بالاتر
        return True

استفاده از این ابزار تضمین می‌کند که فایل گزارش تحت هر شرایطی از روی دیسک آزاد شود.

۲. تراکنش‌های پایگاه داده (Database Transactions)

یکی از حیاتی‌ترین کاربردهای مدیریت بافت، کنترل تراکنش‌های دیتابیس است. در یک سیستم بانکی، عملیات انتقال وجه شامل دو بخش است: کسر از حساب مبدا و واریز به حساب مقصد. اگر عملیات اول موفق باشد اما عملیات دوم خطا دهد، سیستم باید تغییرات را لغو کند (Rollback). در صورت موفقیت کامل، تغییرات نهایی می‌شوند (Commit).

class DatabaseTransaction:
    def __init__(self, db_session):
        self.session = db_session

    def __enter__(self):
        self.session.begin_transaction()
        return self.session

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is not None:
            # در صورت بروز هرگونه خطا، تغییرات لغو می‌شوند
            self.session.rollback()
            print("تراکنش به دلیل خطا لغو شد.")
            return False
        else:
            # در صورت اجرای موفق، تغییرات ثبت نهایی می‌شوند
            self.session.commit()
            print("تراکنش با موفقیت ثبت شد.")
            return True

۳. کنترل قفل‌ها در برنامه‌نویسی چندنخی (Multithreading Locks)

هنگامی که چند نخ (Thread) به طور هم‌زمان قصد تغییر یک متغیر مشترک یا نوشتن در یک منبع واحد را دارند، پدیده Race Condition رخ می‌دهد. برای حل این مشکل از قفل‌ها (Locks) استفاده می‌شود. اگر یک نخ قفلی را فعال کند و در میانه راه با خطا متوقف شود، قفل هرگز باز نشده و سایر نخ‌ها تا ابد معلق می‌مانند (Deadlock).

ماژول درونی threading در پایتون به طور بومی از پروتکل مدیریت بافت پشتیبانی می‌کند:

import threading

shared_resource_lock = threading.Lock()
account_balance = 1000

def update_balance(amount):
    global account_balance
    # دستور with قفل را فعال کرده و در پایان به طور قطعی آزاد می‌کند
    with shared_resource_lock:
        new_balance = account_balance + amount
        if new_balance < 0:
            raise ValueError("موجودی کافی نیست.")
        account_balance = new_balance

جمع‌بندی دوره مدیریت منابع

دستور with کنترل چرخه حیات منابع را از دوش برنامه‌نویس برمی‌دارد و به مفسر پایتون واگذار می‌کند. استفاده از کدهای کثیف قدیمی و بلوک‌های پیچیده شرطی، شانس بروز باگ‌های پنهان را افزایش می‌دهد. توسعه‌دهندگان حرفه‌ای با به‌کارگیری مدیریت بافت اختصاصی (چه از طریق کلاس و چه با دکوراتور contextmanager)، کدهایی ضدگلوله، خوانا و سازگار با استانداردهای پایتونیک خلق می‌کنند.