پایان پشتیبانی Python 3.10؛ برنامه مهاجرت را از کجا شروع کنیم؟

چه خبری منتشر شده و چه تصمیمی لازم است؟

تیم Python در اول اکتبر ۲۰۲۶ اعلام کرد نسخه 3.10.22 آخرین انتشار شاخه 3.10 است و این شاخه دیگر به‌روزرسانی امنیتی دریافت نمی‌کند. همان اطلاعیه انتشار نسخه‌های نگهداری و امنیتی شاخه‌های دیگر را هم معرفی می‌کند. برای سازمانی که هنوز 3.10 اجرا می‌کند، اقدام اصلی ساختن برنامه مهاجرت است، نه صرفاً نصب آخرین patch آن. پایان پشتیبانی به معنی توقف فوری برنامه نیست؛ به معنی تغییر وضعیت رسیدگی به خطاهای آینده است. اول مشخص کنید این runtime در کدام سرویس‌ها، jobها و ابزارهای تیم استفاده می‌شود.

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

مهاجرت فقط عوض کردن executable نیست

فهرست وابستگی مستقیم و گذرا، روش نصب و فایل lock را ثبت کنید. برای نسخه مقصد یک virtual environment تازه بسازید و نصب را از همان فایل وابستگی کنترل‌شده انجام دهید؛ محیط قدیمی را درجا جایگزین نکنید. بسته‌هایی که برای سیستم‌عامل و معماری شما wheel ندارند ممکن است نیازمند کامپایل شوند. پیشنهاد تحریریه این است که نصب و تست را در همان image یا ماشین هدف تکرار کنید تا موفق بودن روی لپ‌تاپ، سازگاری محیط اجرا فرض نشود. import موفق فقط نخستین بررسی است، نه معیار نهایی.

رفتارهایی مانند serialization، annotation، اجرای هم‌زمان و خطاهای TLS را با مسیر واقعی برنامه آزمایش کنید. نسخه 3.14 امکاناتی مثل InterpreterPoolExecutor دارد؛ اما بهره‌گیری از آن باید بعد از تثبیت مهاجرت بررسی شود. تغییر هم‌زمان runtime و معماری هم‌زمانی، علت خطا و افت عملکرد را نامشخص می‌کند. در مثال، یک تابع مستقل CPU-bound در interpreterهای جدا اجرا می‌شود. داده ساده برای ارسال بین محیط‌ها انتخاب شده است؛ اتصال دیتابیس، objectهای زنده و کتابخانه native را نمی‌توان بدون بررسی سازگاری به این مسیر منتقل کرد.

قبل از انتشار، baseline زمان پاسخ، مصرف حافظه، نرخ خطا و مدت jobهای مهم را از نسخه فعلی بگیرید. سپس نسخه مقصد را با همان داده و شرایط بار مقایسه کنید. اگر اختلاف دیده شد، آن را به dependency، runtime یا تغییر کد نسبت دهید و شواهد ثبت کنید. پیشنهاد عملی این است که یک سرویس کم‌ریسک را ابتدا جابه‌جا کنید و برای بازگشت، artifact قبلی را نگه دارید. برنامه پایش پس از انتشار باید مالک داشته باشد؛ پایان نصب، پایان مهاجرت نیست.

نمونه کد و روش بررسی

این مثال آموزشی برای فهم مسیر پیاده‌سازی نوشته شده است. نسخه‌ها و پیش‌نیازهای ذکرشده را در محیط آزمایش بررسی کنید؛ نکات زیر مشخص می‌کنند برای استفاده عملی چه چیزهایی باید تکمیل شوند.

Python 3.14+؛ فایل مستقل بدون وابستگی خارجی

from concurrent.futures import InterpreterPoolExecutor

def sum_of_squares(limit: int) -> int:
    return sum(i * i for i in range(limit))

if __name__ == "__main__":
    inputs = [1000, 2000, 3000]
    with InterpreterPoolExecutor(max_workers=2) as pool:
        parallel = list(pool.map(sum_of_squares, inputs))
    sequential = [sum_of_squares(n) for n in inputs]
    assert parallel == sequential
    print(parallel)

نمونه را به شکل فایل، نه تابعی تعریف‌شده در REPL، در Python 3.14 اجرا کنید. خروجی باید [332833500, 2664667000, 8995500500] باشد. این داده کوچک برای درستی نتیجه است و benchmark سرعت نیست. کار مستقل CPU-bound را با اندازه واقعی بسنجید؛ overhead برای کار کوچک می‌تواند از سود موازی‌سازی بیشتر شود. کتابخانه‌ها و داده قابل انتقال را قبل از استفاده بررسی کنید.

نسخه تازه را با معیار کار خود بسنجید

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