چرا پایتون ۴ مثل پایتون ۳ نخواهد بود
تازه‌واردان در دنیای ایده‌های پایتونی گهگاه در هنگام طرح پیشنهاد تغییرات ناسازگاری عقب رو که مسیر مهاجرتی خاصی از قانون فعلی کد پایتون ارائه نمی‌دهد، به ایده‌ی «پایتون ۴۰۰۰» اشاره میکنند. به هرحال، ما اجازه‌ی این قبیل تغییرات در پایتون ۳ را داده‌ایم، پس چرا برای پایتون ۴ این مجوز را صادر نمی‌کنیم؟!
شخصاً این سوال را تا حالا دیگر به حد کافی شنیدم (از جمله عبارت نگران کننده‌ی: "شما یک بار قبلاً قطع صفحه‌ی سازگاری عقب روی بزرگی را انجام دادید، چطور بدانم دوباره انجامش نمی‌دهید؟ ")، و به این نتیجه رسیدم که پاسخم را اینجا ثبت کنم، بنابراین در آینده میتوانم افراد را به اینجا ارجاع دهم.
انتظارات فعلی از پایتون 4.0 چیست؟
انتظار من این که پایتون ۴ صرفاً نسخه‌ای است که بعد از پایتون ۳.۹ عرضه میشود. فقط همین. بدون تغییر اساسی در زبان، بی هیچ قطع صفحات سازگاری عقب روی بزرگ؛ رفتن از پایتون نسخه‌ی ۳.۹ به ۴ باید همانند رفتن از پایتون ۳.۳ به ۳.۴ (یا از ۲.۶ به ۲.۷) کسل کننده باشد. حتی انتظار دارم که رابط دودویی برنامه‌ی پایدار (که برای نخستین بار در پِپ ۳۸۴ ارائه شد) در آن سوی مرز نیز حفظ شود.
نرخ فعلی انتشار ویژگی‌های زبان (تقریباً هر ۱۸ ماه یکبار)، به این معناست که احتمالاً در طی سال ۲۰۲۳ بجای پایتون ۳.۱۰، شاهد پایتون ۴ خواهیم بود.
خب پایتون چگونه به تکامل ادامه می‌دهد؟
اولین و مهم‌ترین چیز این است، هیچ چیز درباره‌ی پروسه‌ی PEP (مجموعه دستورالعمل هایی برای نوشتن کدی تمیز تر و خوانا تر) تغییر نکرده - با اضافه شدن ماژول‌های جدید (مانند asyncio) و ویژگی‌های زبانی (مانند yield و from) به منظور افزایش قابلیت های موجود در برنامه‌های پایتون، تغییرات سازگاری عقب‌رو کماکان همیشه در حال پیشنهاد شدن هستند. با گذشت زمان، پایتون ۳ از نظر قابلیت‌هایی که به شکل پیش‌فرض ارائه می‌کند، بیشتر و بیشتر از پایتون ۲ جلو خواهد زد، حتی اگر کاربران پایتون ۲ از طریق ماژول‌های شخص ثالث و یا بک پورت های پایتون ۳ بتوانند، به قابلیت‌هایی مشابه آن دست یابد.
مفسرهای در حال رقابت نیز به دنبال کشف راهی برای تسهیل استفاده از پایتون، از جمله ابداع نسل مترجم JIT و حافظه معاملات نرم‌افزاری توسط پی‌پی، همچنین کاوش جامع علمی و تجزیه و تحلیل داده‌های برنامه‌نویسی آرایه‌ای که از تمام توانایی های برداریِ پردازنده ها و کارت‌های گرافیک مدرن استفاده می‌کند، هستند. ادغام با سایر زمان‌های اجرایی ماشین های مجازی (مانند JVM و CLR) نیز انتظار می‌رود با گذشت زمان ارتقاء پیدا کند، به ویژه روشی که پایتون در ورود به سیستم آموزشی پیش گرفته به احتمال زیاد باعث محبوبیت بیشترش به عنوان یک زبان برنامه‌نویسی تعبیه شده در برنامه‌های بزرگتری که در آن محیط‌ها در حال اجرا هستند می‌گردد.
در رابطه با تغییرات ناسازگاری عقب‌رو، پپ ۳۸۷ توضیح مختصر منطقی‌ای از رویکردهایی که سال‌ها در مجموعه‌ی پایتون ۲ از آنها استفاده میشد و هنوز هم میشود، ارائه می‌دهد: اگر مشخص شود یک ویژگی بیش از حد مشکل آفرین است، ممکن است منسوخ و در نهایت حذف گردد.
هرچند یک سری تغییرات دیگر در توسعه و فرآیند انتشار اتفاق افتاده که احتمال نیاز داشتن به چنین استهلاکاتی در مجموعه‌ی پایتون ۳ کاهش می‌یابد:
تاکید بیشتر بر شاخص بسته‌ی پایتون، همانطور که توسط همکاری بین تیم توسعه‌ی هسته‌ی CPython و سازمان مدیریت بسته‌ی پایتون (PyPA)، همچنین همراهی بسته‌ی جانبی pip با پایتون نسخه‌ی ۳.۴ و بالاتر، نشان داده که فشار افزودن ماژول ها به نسخه‌ی استاندارد کتابخانه، قبل از رسیدن به حد توانمندی کافی برای اصلاح به روز رسانی چرخه‌ی نسبتاً کند زبان، را کاهش می‌دهد.
مفهوم API موقت (که در PEP 411 معرفی شد) امکان اجرای دوره‌ی "استقرار" در کتابخانه‌ها و API هایی که احتمال می‌رود با بازخورد گسترده‌تری مواجه شوند را قبل از ارائه‌ی تضمین‌های استاندارد سازگاری عقب‌رو، می‌دهد.
بسیاری از رفتارهای ارثی متراکم در واقع در انتقال به پایتون ۳ حذف شده است، و اکنون الزامات اضافات جدید به پایتون و کتابخانه استاندارد بسیار سخت تر از آنچه در روزگار پایتون نسخه‌ی ۱ و ۲ و ورژن‌های مختلف آنها بوده، می‌باشد.
توسعه‌ی گسترده‌ی کتابخانه‌ها و فریمورک های «تک منبع» در پایتون ۲/۳ شدیداً مشوق استفاده از تقبیح مستند در پایتون ۳ بود، حتی با تعویض ویژگی‌های قبلی با گزینه‌های ترجیحی و تازه‌تر. در این موارد، یک زنگ‌خطر برای رویت تقبیحات در اسناد تعبیه میشود که روش ترجیحی برای رسیدن به کد جدید را پیشنهاد می‌کند، اما هیچ اخطار برنامه‌ای تازه‌ای اضافه نمی‌گردد. این موضع به کد فعلی -از جمله کدهای پشتیبانی شونده در پایتون ۲ و ۳- اجازه می‌دهد که (به قیمت محول کردن وظیفه‌ای داشتن دانش بالاتر و تلاش برای یادگیری بیشتر مباحث حفاظت از پایگاه‌های کد موجود، به کاربران جدید) دست نخورده باقی بمانند.
از (اغلب) انگلیسی به تمام زبان‌های نوشتاری
همچنین لازم به ذکر است که پایتون ۳ همانطور که مشاهده می‌کنیم، مشکل آفرین است. از بین تمام تغییرات ناسازگاری عقب‌رو در پایتون ۳، بسیاری از موانع جدی مهاجرتی، را میتوان توسط یک خط موجود در بحث PEP 3100 (پپ ۳۱۰۰) شرح داد:
همه‌ی رشته‌ها را یونی‌کد کنید، و نوع ()bytes جداگانه داشته باشید. نوع جدید رشته، str نامیده میشود.
پِپ ۳۱۰۰ محل تغییراتی در پایتون ۳ بود که به اندازه‌ی کافی جدال برانگیز نبودند تا یک پپ جداگانه برایشان در نظر گرفته شود. دلیل جدال برانگیز نبودن این مجموعه تغییر بخصوص این بود که تجربه‌ی ما از پایتون ۲ نشان داده بود که حق با نویسندگان قالب‌های وب و رابط‌های کاربری گرافیکی است: برخورد معقولانه با یونی‌کد به عنوان یک توسعه‌دهنده برنامه به معنای حصول اطمینان از تبدیل شدن تمام داده‌های متنی از باینری به نزدیک‌ترین فاصله ممکن از مرز فهم سیستم، به عنوان متن دستکاری شده، و سپس تبدیل مجدد به باینری برای اهداف خروجی است.
متاسفانه پایتون ۲ برنامه‌نویسان را برای کدنویسی به این روش ترغیب نمی‌کند بلکه به طور گسترده‌ای مرز بین داده‌های باینری و متن را محو می‌کند و نگه داشتن مجزای این دو مفهوم را حتی در ذهن توسعه‌دهندگان مشکل می‌سازد، چه برسد به اعمال جداسازی در کدهایشان. بنابراین نویسندگان قالب‌های وب و رابط‌های کاربری گرافیکی باید به کاربران پایتون ۲ خود اعلام کنند که: ((همیشه از یونی‌کد استفاده کنید. اگر این کار را انجام ندهید، ممکن است هنگام سروکله زدن با ورودی یونی‌کد با باگ‌های مبهم و سخت برای ردیابی مواجه گردید)).
پایتون ۳ متفاوت است: پایتون ۳ فاصله‌ی بیشتری بین قلمروی باینری و قلمروی متنی اعمال می‌کند، و باعث سهولت نوشتن کدهای نرم‌افزاری میشود، در حالی باعث می‌گردد نوشتن کدی که با مرزهای سیستم سروکله دارد، جایی که تمایز بین داده‌های باینری و متنی می‌تواند اساساً کمی مبهم باشد، سخت تر شود. من جزییات بیشتری در رابطه با مدل متنی در پایتون ۲ و ۳ تغییر داشته را جای دیگری نوشته‌ام.
این انقلاب در زمینه‌ی پشتیبانی از یونی‌کد توسط پایتون در مقابل مهاجرت پشت پرده‌ی گسترده‌ای از دستکاری و اعمال تغییر در متن‌های محاسباتی از کد اَسکی «فقط» انگلیسی (که به طور رسمی در سال ۱۹۶۳ تعریف شد) از طریق پیچیدگی مدل داده‌ی باینری + اعلان رمزگذاری (از جمله منطقه C/POSIX و سیستم‌های صفحه‌ی کد ویندوز که در اواخر دهه‌ی ۱۹۸۰ معرفی شدند) و نسخه اولیه‌ی فقط ۱۶ بیتی یونی‌کد استاندارد (انتشار یافته در سال ۱۹۹۱) به مدل نسبتاً فراگیر سیستم کد نقطه‌ی کدهای یونی‌کد (که در ابتدا در سال ۱۹۹۶ عرضه شد سپس به‌روزرسانی های بزرگی هر چند سال یکبار برایش ارائه گشت) بود.
چرا این نکته ذکر شد؟ از آنجا که این تغییر به سمت یونی‌کد به طور پیش‌فرض مختل‌کننده ترین تغییرات ناسازگاری عقب‌رو در پایتون ۳ است و بر خلاف سایر موارد که بیشتر تغییرات زبانی بودند، این مورد قسمتی کوچک از یک تغییر گسترده در صنعت چگونگی نمایش و اعمال تغییر در داده‌ی متنی است. با روشن شدن مسائل خاص زبانی در خلال انتقال به پایتون ۳، ایجاد مانع بسیار بزرگتری برای ورود ویژگی‌های جدید زبان در مقایسه با اوایل کار پایتون و عدم رخ دادن هیچ مهاجرت گسترده دیگری به اندازه‌ی تغییر از داده‌های باینری رمزگذاری شده به مدل‌سازی متنی کنونی در حال انجام در یونی‌کد، نمی‌توانم تغییر دیگری ببینم که این چنین محتاج شکستن ناسازگاری عقب‌رو و دوره‌ی پشتیبانی موازی به سبک پایتون ۳ باشد. در عوض انتظار دارم بتوانیم هر گونه تکامل زبان در آینده در خلال تغییر فرآیندهای مدیرتی معمول را تطبیق دهیم، و هر پیشنهادی که از این طریق قابل مدیریت نباشد فقط به دلیل هزینه‌‌هایی که به شکل غیر قابل قبولی برای جامعه و تیم توسعه دهنده بالا هستند، رد میشود.
