Python 3.15 در آستانه RC؛ قبل از 3.15.0rc1 چه چیزهایی را تست کنیم؟

Python 3.15.0rc1 برای 4 اوت 2026 برنامه ریزی شده و 3.15.0b4 آخرین Beta برنامه ریزی شده است. اگر Library، CLI، Backend یا بسته ای با C Extension نگهداری می کنید، دو روز قبل از RC زمان مناسبی است که Compatibility را به جای حدس با CI و Wheel واقعی اندازه بگیرید. این مقاله یک برنامه تست عملی برای Maintainerها و تیم های Backend ارائه می کند.

وضعیت Python 3.15 در 2 اوت 2026

از دید Release Engineering، مهم ترین نکته Feature List نیست؛ نزدیک شدن به ABI Stability است. تیم Python هدف گذاری کرده بعد از Beta 4 تغییر ABI نداشته باشد و پس از RC1 نیز تغییرات کد را به حداقل برساند. به همین دلیل Maintainerهای Third-party تشویق شده اند همین حالا 3.15 را تست و Pre-release Wheel تولید کنند، اما Release Production معمول خود را تا RC1 عقب بیندازند تا ریسک ABI Break کمتر شود. این پنجره برای پیدا کردن مشکل Dependency و Extension بسیار ارزشمند است؛ بعد از GA، همان مشکل تبدیل به Incident کاربر می شود.

برای تیم مصرف کننده، لازم نیست هر Feature جدید را فوراً Adopt کنید. هدف اول این است که کد موجود روی Runtime جدید بدون Regression اجرا شود. Feature Adoption را بعد از Compatibility قرار دهید. این جداسازی Debug را ساده می کند: اگر همزمان Lazy Import، Typing جدید و Runtime را وارد کنید، هنگام خطا مشخص نیست مشکل از Python 3.15 است یا از Refactor شما.

کدام تغییرات مهم را در تست ها لحاظ کنیم؟

Python 3.15 مجموعه قابل توجهی از تغییرات دارد: Explicit Lazy Imports، `frozendict`، `sentinel`، ابزار Profiling جدید و Tachyon، فعال بودن Frame Pointerها برای Observability، UTF-8 به عنوان Encoding پیش فرض، بهبودهای Typing، Stable ABI برای Free-threaded build و تغییرات JIT. این فهرست به معنای استفاده اجباری نیست. برای Compatibility، مهم تر از همه تغییر Defaultها و بخش هایی است که رفتار Environment یا Binary را عوض می کنند؛ برای مثال Encoding و Extension ABI می توانند بدون تغییر کد Business روی Deployment اثر بگذارند.

Explicit Lazy Imports برای Startup جذاب است، اما قبل از استفاده باید Side-effect Importها را شناسایی کنید. پروژه هایی که Registration، Plugin Discovery یا Monkey Patch را با import side effect انجام می دهند، باید ترتیب initialization را تست کنند. `frozendict` و `sentinel` فرصت ساده سازی الگوهای قدیمی اند ولی تا وقتی حداقل نسخه پروژه 3.15 نشده، اضافه کردن آن ها می تواند Compatibility پایین دست را بشکند. Feature جدید را فقط وقتی وارد Public API کنید که Version Policy پروژه روشن باشد.

ABI، Wheel و Extensionهای C؛ حساس ترین بخش مهاجرت

اگر Dependency شما C Extension دارد، سبزشدن Unit Test روی ماشین Maintainer کافی نیست. باید Build و نصب Wheel را در محیط های هدف تست کنید. Python.org صریحاً ساخت Pre-release Wheel برای 3.15 را تشویق کرده چون به دیگر پروژه ها اجازه می دهد زنجیره Dependency خود را آزمایش کنند. اگر Package شما با pybind11، Cython، Rust/PyO3 یا C API مستقیم ساخته می شود، Job جداگانه برای 3.15 اضافه کنید و خطاهای compile، symbol و import را مستقل ثبت کنید.

strategy:
  matrix:
    python-version: ['3.12', '3.13', '3.14', '3.15-dev']
steps:
  - uses: actions/setup-python@v6
    with:
      python-version: ${{ matrix.python-version }}
  - run: python -m pip install -U pip
  - run: python -m pip install -e .
  - run: python -m pytest

نام دقیق pre-release در CI به Tooling شما بستگی دارد، بنابراین مثال بالا را به Runner و setup-python فعلی پروژه تطبیق دهید. هدف مفهومی این است که 3.15 Job اختیاری و قابل مشاهده داشته باشد تا قبل از اجباری شدن Support، Failureها ثبت شوند. برای بسته های Native، build matrix سیستم عامل و معماری از Version matrix مهم تر می شود؛ یک Wheel موفق روی Linux x64 تضمین سازگاری macOS arm64 نیست.

چطور 3.15 را بدون خراب کردن Pipeline به CI اضافه کنیم؟

در مرحله Beta/RC، Job جدید را `allow-failure` یا معادل غیرمسدودکننده قرار دهید، ولی Notification آن را خاموش نکنید. Maintainer باید شکست را ببیند و Issue بسازد. بعد از RC1 و پایدارشدن Dependencyهای اصلی، Job را Required کنید. همچنین lockfile را با Resolver واقعی 3.15 تست کنید؛ گاهی خود کد شما سالم است اما یک Dependency marker یا Wheel نبودن Package باعث می شود نصب شکست بخورد. این دسته خطاها فقط با `pytest` روی Environment موجود پیدا نمی شوند.

Matrix را بیش از حد بزرگ نکنید. اگر پنج سیستم عامل، چهار معماری و ده نسخه Python را Cross Product کنید، هزینه CI بالا می رود و Signal گم می شود. یک Tier بسازید: Tier 1 نسخه های Production، Tier 2 نسخه آینده روی دو Platform کلیدی، Tier 3 Nightly/Experimental. برای 3.15 در این لحظه، Tier 2 انتخاب منطقی است. روی پروژه های Library، downstream test چند مصرف کننده مشهور نیز ارزشمند است چون Public API break را بهتر از Unit Test داخلی آشکار می کند.

Runtime، Encoding و Startup را اندازه بگیرید

UTF-8 به عنوان Encoding پیش فرض یکی از تغییراتی است که می تواند Testهای «روی سیستم من کار می کند» را تغییر دهد. فایل های Legacy با Encoding محلی، CSVهای قدیمی، subprocessها و ابزارهایی که `open()` را بدون `encoding=` صدا می زنند باید بررسی شوند. بهترین practice همچنان Explicit Encoding برای فرمت شناخته شده است. اگر داده شما UTF-8 است آن را صریح بنویسید؛ اگر Windows-1256 یا Encoding دیگری است، همین را اعلام کنید. تکیه به Default Runtime Migration را شکننده می کند.

هم زمان Startup را Benchmark کنید، مخصوصاً اگر CLI یا Function کوتاه عمر دارید. Lazy Importها و JIT جدید می توانند Performance profile را تغییر دهند، ولی عدد رسمی عمومی نباید به عملکرد اپ شما تعمیم داده شود. Benchmark خودتان را با Warm/Cold run، dataset ثابت و چند تکرار بگیرید. برای Server طولانی عمر، Throughput و Memory مهم تر از Startup چند میلی ثانیه ای است؛ برای CLI برعکس. نتیجه خوب مقاله یا Release Note جای Measurement workload شما را نمی گیرد.

Typing و Public API؛ تغییر را به مصرف کننده تحمیل نکنید

3.15 امکانات Typing تازه ای مثل TypedDict با extra itemهای تایپ شده و TypeForm دارد. Library Maintainer باید بین «استفاده داخلی» و «ظاهرشدن در Annotation عمومی» فرق بگذارد. اگر Annotation جدید در فایل های Runtime import شود، ممکن است Support نسخه های قدیمی را بشکند. استفاده از `typing_extensions` یا Guardهای version-dependent می تواند گذار را نرم کند. قبل از تغییر Public Type Contract، mypy/pyright و حداقل نسخه پشتیبانی شده را در Matrix تست کنید.

`frozendict` و `sentinel` نیز وسوسه انگیزند چون الگوهای رایج را استاندارد می کنند. اما مهاجرت API عمومی باید SemVer-aware باشد. اگر کاربران هنوز Python 3.12 یا 3.13 دارند، نوعی که فقط در 3.15 وجود دارد Public Contract شما را به Runtime جدید قفل می کند. ابتدا Internal usage یا Optional codepath، بعد افزایش minimum version و در نهایت Public API؛ این ترتیب هزینه Adoption را برای مصرف کننده کمتر می کند.

چه زمانی Production را روی Python 3.15 ببریم؟

در 2 اوت پاسخ عمومی «امروز نه» است، چون نسخه فعلی Preview است و Python.org استفاده Production را توصیه نمی کند. اما این به معنی صبر منفعلانه تا GA نیست. امروز CI و Compatibility را آماده کنید؛ بعد از RC1 می توانید Staging و Pre-release artifact را جدی تر آزمایش کنید. برای GA، معیار شما باید آماده بودن Dependencyهای Critical، Wheelهای معماری هدف، Observability و Rollback باشد. پروژه ای که روز GA تازه شروع به تست می کند عملاً چند هفته عقب تر است.

1. امروز: 3.15 را به CI غیرمسدودکننده اضافه کنید.
2. تا RC1: Dependency و Wheel blockerها را Issue کنید.
3. بعد از RC1: Staging، Benchmark و Packaging واقعی را اجرا کنید.
4. پیش از GA Adoption: minimum-version policy و rollback runtime را مستند کنید.
5. پس از Adoption: warning/deprecation و رفتار Encoding را در Production telemetry دنبال کنید.

پرسش های متداول

Python 3.15.0rc1 چه زمانی منتشر می شود؟

طبق برنامه رسمی، RC1 برای 4 اوت 2026 زمان بندی شده است.

آیا 3.15.0b4 برای Production مناسب است؟

خیر. Python.org این نسخه را Preview می داند و استفاده Production را توصیه نمی کند.

چرا Maintainerها باید قبل از RC Wheel بسازند؟

برای آشکارشدن مشکل ABI، Compiler و Dependency در زنجیره اکوسیستم قبل از Release نهایی.

مهم ترین ریسک اپ های خالص Python چیست؟

Dependency compatibility، تغییر Defaultهایی مثل Encoding، deprecationها و رفتار import/startup از موارد مهم اند.

آیا باید از Featureهای جدید همین حالا استفاده کنیم؟

برای مرحله Compatibility بهتر است نه؛ ابتدا کد فعلی را روی Runtime جدید سبز کنید و Feature Adoption را جداگانه انجام دهید.

منبع اصلی و جمع بندی

تاریخ RC، توصیه Maintainerها، وضعیت ABI و فهرست Featureهای اصلی از صفحه رسمی Python 3.15.0b4 گرفته شده است. بهترین استفاده از دو روز باقی مانده تا RC1 این نیست که Production را زود ارتقا دهید؛ این است که Failureهای آینده را امروز در CI پیدا کنید.

چک لیست Maintainer قبل از RC

• تست روی 3.15 را به CI اضافه کنید و Failure را Issue کنید.
• Dependency resolver را از Environment خالی اجرا کنید، نه از venv قدیمی.
• Wheel یا Source build را روی معماری های اصلی آزمایش کنید.
• فایل های متنی را برای `encoding` ضمنی جست وجو کنید.
• Import side effectها را قبل از استفاده از Lazy Import شناسایی کنید.
• Warningهای Deprecation را در Test به خطا تبدیل کنید تا بدهی پنهان بماند.
• Benchmark را با workload واقعی و baseline 3.14 ثبت کنید.
• Public typing API را با minimum Python version پروژه سازگار نگه دارید.

Packaging را مثل یک محصول مستقل تست کنید

بسیاری از مهاجرت های Python در Source Code سبز می شوند اما در مرحله نصب شکست می خورند. علت این است که کاربر نهایی معمولاً Repository را Clone نمی کند؛ او Wheel، sdist یا Image شما را نصب می کند. بنابراین در Matrix سازگاری 3.15، نصب از Artifact ساخته شده را جدا از اجرای Test Suite بررسی کنید. برای Library عمومی، Wheel را در محیط تمیز نصب کنید و Import ساده، CLI entry point و Feature اصلی را اجرا کنید. برای Backend، Image نهایی را از همان Dockerfile Production بسازید تا Base Image، Compiler package و Native dependencyها نیز وارد آزمون شوند.

اگر Package شما C/C++ یا Rust Extension دارد، شکست فقط به خود CPython محدود نیست. Toolchain سیستم عامل، نسخه `manylinux`، macOS deployment target و Availability Wheel وابستگی های پایین دستی نیز دخیل اند. نتیجه تست را به سه دسته تقسیم کنید: مشکل کد خودتان، مشکل Dependency و مشکل Toolchain. این تفکیک باعث می شود Issue دقیق برای Maintainer upstream باز شود و تیم شما بی دلیل Workaround دائمی نسازد. تا وقتی RC1 نرسیده، Pre-release Artifact را کانال آزمایشی نگه دارید و آن را جایگزین Release پایدار برای کاربران عادی نکنید.

Deprecatedها و Defaultهای تازه را قبل از روز Upgrade پیدا کنید

تست «همه Unit Testها سبز شدند» برای Runtime major کافی نیست. اجرای Suite با Warningهای قابل مشاهده می تواند APIهایی را نشان دهد که امروز کار می کنند اما در چرخه بعدی حذف می شوند. Warning suppressionهای قدیمی را بازبینی کنید و در CI یک Job جدا بسازید که DeprecationWarningهای پروژه خودتان را جدی تر گزارش کند. همزمان مسیرهایی را که به Encoding پیش فرض، startup configuration یا import behavior متکی هستند با ورودی واقعی تست کنید؛ تغییر Default زمانی دردناک می شود که Assumption پنهان در اسکریپت Deployment یا ابزار داخلی باشد، نه در تابعی که Unit Test دارد.

برای اپ چندسیستمی، Fixtureهای فایل و Subprocess را روی Windows، Linux و macOS جدا اجرا کنید. تفاوت Path، Shell، locale و native wheel می تواند نتیجه متفاوت بدهد. یک RC readiness report کوتاه تهیه کنید که شامل نسخه Dependencyهای Blocker، لینک Issue upstream، وضعیت Wheel و نتیجه Platformها باشد. با این گزارش، تصمیم ارتقا در زمان Release نهایی بر اساس شواهد گرفته می شود؛ نه اینکه همان روز تازه بفهمید یک Package حیاتی هنوز 3.15 را پشتیبانی نمی کند.