بايثون 3.15: لماذا لم يمت الـGIL، ولماذا لا يهمّ ذلك كثيراً؟

في الأول من أكتوبر 2026 تصل Python 3.15 رسمياً، وقبلها بشهر نزل آخر مرشّح إصدار لها. ومع كل اقتراب من إصدار جديد يعود العنوان نفسه إلى الواجهة: «انتهى عصر الـGIL». العنوان مثير، ومشاركاته بالآلاف، وهو — بصيغته هذه — غير صحيح.

القفل العام للمفسّر (Global Interpreter Lock) ما زال موجوداً في البناء الافتراضي لبايثون 3.15، وسيبقى. ما تغيّر فعلاً شيء آخر تماماً، أقل إثارة بكثير وأهم بكثير: أُزيل الحاجز الذي كان يمنع مكتبات الطرف الثالث من دعم النسختين معاً. هذا هو الخبر، وهذا ما يقرّر متى ستستفيد أنت عملياً.

ما هو الـGIL ولماذا يهمّك أصلاً

الـGIL قفل واحد داخل المفسّر يضمن أن خيطاً واحداً فقط ينفّذ شيفرة بايثون في اللحظة الواحدة. وجوده جعل بناء المفسّر والمكتبات المكتوبة بلغة C أبسط وأأمن لعقود، لكنه يعني أن برنامجاً متعدّد الخيوط على معالج بثمانية أنوية قد لا يستغلّ إلا نواة واحدة في العمليات الحسابية الخالصة.

الالتفاف التقليدي كان تشغيل عمليات (processes) منفصلة بدل خيوط، وهو حل يعمل لكنه مكلف: كل عملية نسخة كاملة من المفسّر بذاكرتها، وتبادل البيانات بينها يحتاج تسلسلاً ونسخاً.

أين وصلنا فعلاً: ثلاث مراحل، اكتملت اثنتان

خطة إزالة القفل موضوعة منذ سنوات على ثلاث مراحل واضحة:

المرحلة	الحالة	ماذا تعني
تجريبية	اكتملت (3.13)	بناء منفصل، غير مضمون الاستقرار
مدعومة رسمياً	اكتملت (3.14)	بناء منفصل، مدعوم ومستقر
البناء الافتراضي	لم تبدأ	لا إصدار مُلتزَم به حتى الآن

النسخة بلا قفل تُثبَّت وتُشغَّل كمفسّر مستقل باسم ينتهي بحرف t، بجانب المفسّر العادي لا بدلاً منه. هذا كان صحيحاً في 3.14، وما زال صحيحاً في 3.15. من يقرأ عنواناً يقول «القفل اختفى» ثم يثبّت بايثون 3.15 بالطريقة المعتادة، سيحصل على مفسّر يحتوي القفل كما كان بالضبط.

الخبر الحقيقي في 3.15: واجهة ثنائية واحدة للنسختين

المشكلة التي أخّرت كل شيء لم تكن في المفسّر، بل في المكتبات. أي مكتبة مكتوبة بلغة C — وهي العمود الفقري لتحليل البيانات والذكاء الاصطناعي ومعالجة الصور — كانت تحتاج أن تُبنى مرّتين: نسخة للمفسّر العادي ونسخة للمفسّر بلا قفل. صائن مكتبة يديرها في وقته الخاص يرى هنا مضاعفة في مصفوفة البناء وفي عدد الملفات الجاهزة وفي بلاغات الأخطاء.

3.15 تقدّم واجهة ثنائية مستقرة تغطّي النسختين معاً: تبني مرّة واحدة، فتعمل الحزمة على الاثنين. هذا يختصر نصف العمل من على كاهل الصائنين، وهو السبب الوحيد الذي سيجعل التغطية تتسع فعلاً خلال 2026 و2027.

لكن انتبه: التحوّل ليس تلقائياً. على صائن المكتبة تعديل شيفرته لاستخدام الواجهات الجديدة وتغيير نقطة الدخول التي يعلن بها عن نفسه للمفسّر. الأدوات الكبرى في هذا المجال أضافت الدعم بالفعل، لكن كل مكتبة قرار مستقل بذاته.

الفخّ الذي لا يظهر في أي رسالة خطأ

هذه أخطر نقطة عملية في الموضوع كله، وتبقى قائمة في 3.15:

إذا استوردت مكتبة مكتوبة بلغة C لم تعلن صراحةً أنها آمنة مع الخيوط، يعيد المفسّر تفعيل القفل للعملية بأكملها — بصمت. البرنامج لا يتعطّل، والخيوط تعمل، لكنها لا تعمل بالتوازي.

تخيّل الموقف: فريق يهاجر إلى المفسّر بلا قفل، يقيس الأداء، فلا يجد فرقاً يُذكر، ويستنتج أن «الموضوع مبالغ فيه». الحقيقة أن سطر استيراد واحد في ملف جانبي أعاد القفل من الباب الخلفي. من دون التحقّق من حالة القفل أثناء التشغيل، لا توجد وسيلة لاكتشاف ذلك من سلوك البرنامج.

كيف تتحقّق قبل أن تستنتج

1. شغّل المفسّر بلا قفل وتحقّق من حالة القفل بعد استيراد كل اعتماديات مشروعك، لا قبلها.
2. افعل ذلك على الشيفرة الحقيقية، لا على سكربت اختبار من خمسة أسطر.
3. إن عاد القفل، استورد المكتبات واحدة واحدة لتحديد المسؤول.
4. راجع صفحة المشروع المسؤول: غالباً ستجد نقاشاً مفتوحاً وجدولاً زمنياً.

تغيير آخر في 3.15 سيمسّك أكثر

بعيداً عن الخيوط تماماً، 3.15 تحسم قراراً قديماً: UTF-8 صار الترميز الافتراضي عند فتح الملفات على كل أنظمة التشغيل، بصرف النظر عن إعدادات اللغة في النظام.

للمطوّر العربي تحديداً هذه أهم جملة في الإصدار كلّه. صنف الأخطاء الذي يعمل على جهاز المطوّر ويفشل على خادم آخر — أو يحوّل نصاً عربياً سليماً إلى رموز مشوّهة — مصدره في الغالب اختلاف الترميز الافتراضي بين البيئتين. توحيده يقتل هذه الفئة من الأخطاء من جذرها.

الوجه الآخر: إن كان لديك شيفرة قديمة تعتمد ضمنياً على ترميز النظام المحلّي لقراءة ملفات مكتوبة بترميز آخر، فقد يتغيّر سلوكها بعد الترقية. الحل المباشر هو تحديد الترميز صراحةً عند فتح أي ملف بدل الاعتماد على الافتراضي، وهي ممارسة كانت صحيحة قبل 3.15 أصلاً.

ماذا تفعل عملياً الآن

• في الإنتاج: رقِّ إلى 3.15 العادي بعد اختبار طبيعي، وانتبه لتغيّر الترميز الافتراضي.
• في بيئة الاختبار: جرّب المفسّر بلا قفل على عبء عمل حقيقي محصور بالمعالج، وقِس قبل أن تحكم.
• لا تنقل الإنتاج إلى المفسّر بلا قفل اليوم إلا إذا كانت كل اعتمادياتك تدعمه صراحةً وقِستَ مكسباً حقيقياً.
• إن كنت تنشر مكتبة بلغة C: هذا هو وقت الانتقال للواجهة الجديدة — الطلب سيأتي، والانتقال المبكر أرخص.
• راقب الاعتماديات لا الإصدارات: تاريخ استفادتك من إزالة القفل يحدّده أبطأ مكتبة في مشروعك، لا رقم إصدار بايثون.

أسئلة شائعة

هل سأحصل على أداء أسرع بمجرد الترقية إلى 3.15؟

لا، ليس في التوازي. البناء الافتراضي يحتفظ بالقفل، فسلوك الخيوط كما هو. المكسب المتوازي يحتاج المفسّر المنفصل بلا قفل، وبيئة اعتماديات تدعمه بالكامل.

هل ستختفي البرمجة متعدّدة العمليات؟

لا. حتى في عالم بلا قفل تبقى العمليات المنفصلة مفيدة لعزل الأعطال والأمان وتوزيع العمل على أجهزة متعدّدة. ما سيتغيّر أن الخيوط تصبح خياراً معقولاً حيث كانت العمليات هي الحل الوحيد.

متى يصبح البناء بلا قفل هو الافتراضي؟

لا يوجد إصدار مُلتزَم به. القرار مرتبط بنضج المكتبات وبتكلفة الأداء في الحالة أحادية الخيط، ومن المتوقّع أن تكون التغطية واسعة بما يكفي لمعظم الفرق في الإصدار الذي يليه، لا في 3.15.

الخلاصة

بايثون 3.15 ليست الإصدار الذي «قتل الـGIL»، وأي عنوان يقول ذلك يقرأ خارطة الطريق خطأً. هي الإصدار الذي أزال العائق الهندسي أمام من يملكون القرار الحقيقي: صائنو المكتبات المكتوبة بلغة C. واجهة ثنائية واحدة تعني بناءً واحداً بدل اثنين، وهذا هو الشرط الذي بدونه تظلّ النسخة بلا قفل تجربة معزولة مهما بلغ نضج المفسّر.

والقاعدة العملية التي تستحقّ أن تُكتب على جدار كل فريق: لا يتحدّد موعد استفادتك من ميزة في المفسّر برقم إصدار المفسّر، بل بآخر مكتبة في مشروعك تتبنّاها. أما التغيير الذي ستشعر به فعلاً هذا الشهر فهو الأهدأ صوتاً — توحيد ترميز UTF-8 — وهو بالمناسبة أفضل خبر تلقّاه مطوّر يكتب بالعربية منذ سنوات.