PyPy 8.0 يضيف دعم Python 3.12، لكن الاختبار الحقيقي يكمن في منظومة الامتدادات

يستحق PyPy 8.0 المتابعة لسبب قد لا يظهر مباشرة في رقم الإصدار. فالمشروع لا يطرح مجرد مفسر Python أسرع. إنه يحاول تقليص إحدى الكلف القديمة لاختيار PyPy: الفجوة بين مفسر متوافق مع لغة Python والعالم الأوسع بكثير من الحزم التي تعتمد على واجهة CPython البرمجية بلغة C.

صدر الإصدار في 19 سبتمبر 2026، ويضيف مفسراً بجودة تجريبية للغة Python 3.12، مع استمرار توفير نسختي Python 3.11 وPython 2.7، كما يغيّر خط أساس بناء Linux إلى glibc 2.28. والأهم أن فريق PyPy يقول إن نموذج الكائنات الجديد في Python 3.12 يتضمن الأجزاء اللازمة لاستخدام عجلات cp312-abi3 المبنية لـ CPython وفق الواجهة المحدودة. أما العمل المتبقي فلا يقتصر على PyPy نفسه؛ إذ يجب أن تتفق آليات الاستيراد، وأدوات التثبيت، وأنظمة بناء الحزم على أن تلك العجلات مرشحة صالحة للاستخدام.

لهذا يجعل PyPy 8.0 مناسباً للتجارب واختبارات الإنتاج المحدودة. لكنه ليس تعليمات عامة لاستبدال CPython. السؤال العملي والأكثر فائدة أضيق من ذلك: هل تستطيع مجموعة تبعيات تطبيقك العمل على PyPy 8.0 من دون الرجوع إلى بناء الحزم من المصدر، أو استخدام امتدادات أصلية غير مدعومة، أو الاعتماد على افتراضات لا تصح إلا تحت CPython؟

ما الذي تغيّر في PyPy 8.0

يصف PyPy الإصدار 8.0.0 بأنه إصدار رئيسي يتمحور حول ثلاثة خطوط للمفسر: PyPy2.7 وPyPy3.11 وPyPy3.12. وقد وُسم تنفيذ Python 3.12 صراحة بأنه تجريبي، لذلك ينبغي للمستخدمين التعامل معه بوصفه منصة لاختبار التوافق، لا بديلاً تلقائياً عن نشر CPython ناضج. ويظل خط Python 3.11 متاحاً، بينما يقول المشروع إنه، ما لم تظهر مشكلات أمنية، يتوقع أن يكون هذا آخر إصدار يدعم Python 3.11.

تذكر مذكرة الإصدار الرسمية للمشروع سببين متعلقين بالبنية التحتية وراء الانتقال إلى رقم إصدار رئيسي جديد. أولاً، تستخدم خوادم البناء الآلية في Linux الآن صور manylinux 2.28 المبنية على AlmaLinux 8 وglibc 2.28، مع استبدال سلسلة أدوات GCC 5 الأقدم بـ GCC 14. وبذلك تتطلب أرشيفات tarball المجمعة الناتجة glibc 2.28 أو أحدث. قد يكون هذا خط أساس معقولاً لكثير من التوزيعات الحالية، لكنه يظل قيداً في النشر: يجب فحص صور المؤسسات الأقدم، والأجهزة القديمة، وقواعد الحاويات المجمدة بعناية، لا افتراض توافقها.

ثانياً، غيّر PyPy طريقة عرض تمثيله الداخلي للكائنات أمام امتدادات C. كانت الإصدارات السابقة تكشف امتداداً خاصاً بـ PyPy داخل بنية PyObject بطريقة تجعلها مختلفة عن تخطيط CPython. في الإصدار 8.0، يُخفى الحقل الخاص بـ PyPy داخل بادئة تسبق المؤشر الذي يُسلّم إلى وحدات الامتدادات المكتوبة بلغة C. والهدف المعلن هو تمكين PyPy من استخدام عجلات cp312-abi3 المنتجة لـ CPython 3.12 والإصدارات اللاحقة، بشرط أن تظل تلك العجلات فعلاً ضمن حدود الواجهة المحدودة.

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

كما أسقط PyPy الواجهة الخلفية الداخلية لـ HPy. تقول مذكرة الإصدار إن النهج القائم على المقابض في مشروع HPy كان نموذجاً أولياً مفيداً، لكنه لم يحظَ بالدعم الكافي ليصبح معياراً جديداً. وما تزال شيفرة HPy موجودة في شجرة PyPy ويمكن تفعيلها بخيار بناء، لكنها لم تعد جزءاً من الاتجاه الافتراضي. وبالنسبة إلى مؤلفي الامتدادات، فهذا يعني أن مسار التوافق المباشر ما زال يتمثل في حدود C API الحالية، أو CFFI، أو منطق بناء خاص بالمفسر، لا في انتقال واسع إلى HPy يزيل التنازلات القديمة.

لماذا تهم cp312-abi3

لا تُوزع حزم Python كلها بالطريقة نفسها. فالحزمة المكتوبة بالكامل بـ Python تستطيع غالباً استخدام عجلة py3-none-any والعمل على CPython أو PyPy أو تنفيذ آخر لـ Python 3. أما الحزمة التي تحتوي على شيفرة C أو C++ أو Rust فمختلفة. قد تكون عجلتها مرتبطة بمفسر محدد، وواجهة ABI محددة، ونظام تشغيل، ومعمارية معالج بعينها. ويشفّر اسم الملف هذه الادعاءات المتعلقة بالتوافق.

يصف دليل مستخدم تغليف Python الوسم abi3 بأنه الوسم المستخدم للامتدادات المبنية على ABI المستقرة الخاصة بـ CPython. وABI المستقرة مجموعة فرعية مقيدة من C API صُممت لتظل قابلة للاستخدام عبر إصدارات Python 3. في الحالة المعتادة، تستطيع الحزمة توزيع عجلة واحدة من نوع cp39-abi3 لكل تركيبة من نظام التشغيل والمعمارية، بدلاً من إعادة بناء امتداد منفصل لكل إصدار فرعي من CPython.

لكن هذه الفائدة لا تنتقل تلقائياً إلى PyPy. فالعجلة التي تحمل وسم cp312-abi3 تقدم ادعاءً بشأن ABI المستقرة لـ CPython. لذلك يجب على PyPy توفير تنفيذ متوافق للواجهة المعنية، كما يجب على أدوات التغليف أن تضع العجلة في الحسبان أثناء حل التبعيات. ويقول إصدار PyPy 8.0 إن ترويسات C والدوال المصدّرة أصبحت الآن متوافقة مع الواجهة المحدودة لـ CPython في Python 3.12، لكنه يسمي جزأين مهمين لا يزالان مفقودين: يجب أن تقبل آلية الاستيراد ملفات المشاركة abi3.so بوصفها صالحة لـ PyPy، ويجب أن تتعرف أدوات مثل pip وuv على تلك العجلات باعتبارها مرشحين.

هذا التفريق هو محور الإصدار. قد يكون التغيير على مستوى المفسر صحيحاً تقنياً، لكنه لا يقدم فائدة كبيرة للمستخدمين إذا لم تعتمد فهرسة الحزم، والمثبت، وواجهة البناء الخلفية، ومشروع الامتداد التفسير نفسه. ويمكن تصور سلسلة التوافق تقريباً على النحو التالي:

ترويسات PyPy وآلية تحميله
        ↓
مشروع الامتداد يُبنى ضمن الواجهة المحدودة
        ↓
بيانات العجلة تعلن عن ABI متوافق
        ↓
المثبت يضع العجلة ضمن مرشحي PyPy
        ↓
التطبيق يجتاز اختبارات التشغيل والسلوك

أي انقطاع في هذه السلسلة يعيد المستخدم إلى بناء من المصدر، أو عجلة خاصة بـ PyPy، أو بديل مكتوب بالكامل بـ Python، أو ملف ثنائي غير متوافق. يدفع PyPy 8.0 الجزء الأول من السلسلة إلى الأمام، لكنه لا يلغي الحاجة إلى اختبار الأجزاء الباقية.

ما تزال ملاحظة التوافق كبيرة

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

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

وتشير وثائق Cython إلى نقطة ذات صلة: يستطيع Cython تكييف الشيفرة المولدة لـ PyPy، لكن الفروق تظل موجودة في C API المحاكاة. وتوصي الوثائق مؤلفي الامتدادات بالاعتماد، حيثما أمكن، على المعالجة التي يولدها Cython بدلاً من استخدام سلوك منخفض المستوى في C API مباشرة من دون سبب واضح. وليس ذلك إدانة خاصة بـ PyPy؛ بل تذكير بأن سطح اللغة المستقر وسطح الامتدادات الأصلية المستقر مشكلتان هندسيتان مختلفتان.

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

ويواجه مؤلفو امتدادات Rust قراراً مشابهاً. يدعم PyO3 بناءات PyPy ويوفر إعدادات لاكتشاف تنفيذ PyPy، لكن وثائقه وتعليقات شيفرته ما تزال تتعامل مع ABI المستقرة بوصفها مساراً موجهاً إلى CPython. لذلك ينبغي لمشروع Rust الذي يريد دعم CPython وPyPy أن يبني الهدفين ويختبرهما صراحة. ولا ينبغي استنتاج توافق PyPy لمجرد أن بناء CPython يستخدم abi3.

من ينبغي له تجربة PyPy 8.0 الآن

أفضل المرشحين هم التطبيقات التي تحتوي على حلقات Python طويلة التشغيل، أو قدراً مهماً من الحساب المكتوب بـ Python بالكامل، أو خدمات تستفيد من مترجم PyPy الفوري بالتتبع بعد أن تصبح الشيفرة دافئة. يكون العائد المحتمل أكثر إقناعاً عندما يقضي التطبيق وقتاً كبيراً في شيفرة مستوى Python ووقتاً أقل في انتظار مكتبات أصلية تنجز العمل الثقيل مسبقاً.

ويمثل PyPy أيضاً منصة اختبار مناسبة لمشرفي المكتبات المكتوبة بالكامل بـ Python. فإذا كانت الحزمة تدعي دعماً واسعاً لتطبيقات Python، فإن إضافة PyPy 8.0 إلى مصفوفة التكامل المستمر يمكن أن تكشف افتراضات لا تظهر في اختبارات CPython وحدها. وهذا مفيد بصفة خاصة للمكتبات التي تتعامل بصورة غير مباشرة مع أعمار الكائنات، أو تستخدم الإرسال الديناميكي بكثافة، أو تعد بدعم مفسرات بديلة.

الإصدار مهم كذلك لمشرفي الامتدادات. فالمشروع الذي يستخدم Cython أو CFFI أو PyO3 يستطيع استخدام PyPy 8.0 لمعرفة ما إذا كانت حدوده التجريدية قابلة للنقل فعلاً. ويمنح العمل الجديد حول cp312-abi3 هدفاً ملموساً للتعاون بين PyPy ومؤلفي الامتدادات وأدوات التغليف. فهو يحول طلباً عاماً مثل «اجعل دعم PyPy أفضل» إلى سلسلة مسائل قابلة للاختبار: هل يمكن ترجمة الامتداد؟ هل يمكن تثبيت العجلة؟ هل تُستورد؟ وهل تتصرف بصورة صحيحة أثناء جمع القمامة وتنفيذ المترجم الفوري؟

ينبغي للفرق التي تدير خدمات Python أن تكون أكثر انتقائية. فخدمة ذات شجرة تبعيات محدودة، واختبارات تكامل قوية، وعبء عمل تهيمن عليه شيفرة Python، تمثل مرشحاً معقولاً لتجربة أولية. أما حزمة علوم بيانات تحتوي على تبعيات ثنائية كبيرة متعددة، وبرامج تشغيل قواعد بيانات أصلية، ووحدات Cython مخصصة، وعجلات خاصة بموردين، فهي هدف أول أكثر خطورة بكثير. قد تعمل هذه الحزمة في النهاية، لكن الفائدة المتوقعة يجب أن تبرر كلفة الحفاظ على مسار مفسر آخر.

وأضعف سبب لتجربة PyPy 8.0 هو ببساطة أن رقم الإصدار أكبر من رقم إصدار CPython. فرقم PyPy يتبع تسلسل إصدارات المشروع نفسه؛ ولا يعني أن المفسر ينفذ Python 8. إصدارات اللغة المعنية في هذا الإصدار هي Python 3.12 التجريبية، وPython 3.11، وPython 2.7.

خطة عملية للتقييم

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

بعد ذلك أنشئ بيئة منفصلة لـ PyPy 8.0 وثبّت الحزم باستخدام أداة الحل المعتادة في المشروع. لا تسبق الخطوة بتثبيت مجموعة من عجلات CPython ثم تفترض أن البيئة تمثل الواقع. سجّل الحزم التي تثبت من عجلات، وتلك التي تُبنى من المصدر، وتلك التي تُرفض. يمثل نجاح التثبيت دليلاً مفيداً، لكنه ليس حكماً نهائياً على التوافق.

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

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

أبقِ CPython خط أساس للمقارنة. الهدف ليس إثبات تفوق PyPy في كل اختبار معياري. قارن النتيجة الهندسية الكاملة: موثوقية البناء، وسلوك البدء البارد، والذاكرة، والإنتاجية، وقابلية الرصد، والتصحيح، وتوفر العجلات، والوقت اللازم لإبقاء مساري مفسرين سليمين. ففي عبء دفعي يعمل لساعات قد تكون كلفة الإحماء بسيطة. أما في أداة سطر أوامر تُستدعى مئات المرات في الدقيقة، فقد تمحو الكلفة نفسها الفائدة.

على مستخدمي Linux فحص حد glibc

من السهل تجاهل الانتقال إلى glibc 2.28 لأنه يوصف بوصفه بنية بناء. لكنه جزء من عقد توزيع وقت التشغيل أيضاً. تقول صفحة تنزيل PyPy إن ثنائيات Linux الحالية متوافقة مع manylinux 2.28 والإصدارات اللاحقة، وتذكر أن بناءات Linux تتطلب glibc 2.28 أو أحدث. ومن غير المرجح أن يفاجأ مستخدمو Ubuntu وDebian وFedora الحديثة وأنظمة مشابهة بذلك. أما من يدعمون توزيعات أقدم أو صوراً محدودة فعليهم التحقق مباشرة.

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

يحذر المشروع أيضاً من أن ثنائيات Linux تتضمن OpenSSL لكنها لا تتضمن مخزناً لشهادات الأمان. وتوصي وثائق التنزيل المستخدمين بالاعتماد على مخزن شهادات المنصة أو ضبط SSL_CERT_FILE، مثلاً عبر حزمة certifi. وليس هذا خاصاً بـ PyPy، لكنه نوع التفاصيل التشغيلية الذي قد يضيع عند تنزيل مفسر في أرشيف يبدو مكتفياً بذاته. وينبغي أن تكون اختبارات HTTPS جزءاً من التحقق الأولي، ولا سيما للأدوات التي تتصل بفهارس الحزم أو واجهات API أو الخدمات الداخلية.

التنزيل والتحقق وعزل التجربة

يوفر PyPy أرشيفات مترجمة مسبقاً لعدة منصات، منها Linux x86-64 وLinux ARM64 وWindows 64-bit وmacOS على عتاد Apple Silicon وIntel. وينشر المشروع قيم التحقق الخاصة بأرشيفات 8.0.0. تعامل مع هذه القيم بوصفها جزءاً من عملية التثبيت: نزّل من صفحات المشروع الرسمية، وتحقق من الأرشيف، وسجّل بناء المفسر الدقيق في ملاحظات التجربة.

تجنب استبدال الأمر python الخاص بالنظام أثناء تقييم الإصدار. استخدم بيئة افتراضية مخصصة أو مساراً صريحاً للمفسر، وأبقِ بيئة CPython الحالية سليمة، واجعل الاختيار ظاهراً في التكامل المستمر. فغلاف صغير أو إدخال في مصفوفة الاختبارات أسهل في الإزالة من تغيير مفسر على مستوى الجهاز يبدل بصمت النصوص البرمجية أو مهام البناء أو وحدات الخدمة.

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

ماذا يعني الإصدار لأدوات التغليف

يكشف PyPy 8.0 مشكلة تنسيق أجّلها نظام Python لسنوات. فكثيراً ما يُناقش دعم المفسرات كما لو كان خاصية في وقت التشغيل وحده، بينما اختيار العجلة نتيجة تفاوض بين بيانات الحزمة، ووسوم المثبت، وواجهات البناء الخلفية، وسياسة الفهرس، والتنفيذ الذي يحمّل الملف الثنائي في النهاية. وتوضح صياغة فريق PyPy نفسه أن العمل ما يزال مستمراً في آلية الاستيراد وفي أدوات مثل pip وuv.

يوفر ذلك فرصة عملية لمشرفي الحزم كي يساعدوا. يستطيع المشرف اختبار امتداد المشروع مع PyPy 3.12، ومراجعة ما إذا كان يستخدم الواجهة المحدودة فعلاً، وإضافة مهمة PyPy إلى التكامل المستمر، ونشر عجلة متوافقة عند ملاءمة ذلك، والإبلاغ عن الأعطال مع مثال صغير قابل لإعادة الإنتاج. أما المستخدم الذي يفتح مسألة ويقول فقط «PyPy معطل» فلا يقدم إشارة كبيرة. بينما يتيح بلاغ يقول «العجلة cp312-abi3 تُثبت، لكنها تفشل عندما يُحرر مخزن بعد الجمع» شيئاً يمكن للمنظومة إصلاحه.

وهو تذكير أيضاً بضرورة الدقة في بيانات الحزم. ينبغي للتوزيع المكتوب بالكامل بـ Python أن يستخدم أوسع وسم صادق. وينبغي للامتداد المترجم أن يعلن فقط ABI والمنصات التي اختبرها فعلاً. والمشروع الذي يبني باستخدام ABI مستقرة لكنه يستورد رموزاً خاصة بـ CPython لم يحقق قابلية النقل التي يوحي بها اسم ملفه. ولن يكون العمل حول PyPy 8.0 ذا قيمة إلا إذا أصبحت ادعاءات الحزم أدق، لا أكثر تفاؤلاً فحسب.

البدائل والمكملات

يبقى CPython الخيار الافتراضي لأوسع توافق مع الحزم، وللسلوك الأكثر قابلية للتنبؤ في الامتدادات الأصلية، ولأكبر مجموعة من العجلات المدعومة من الموردين. وبالنسبة إلى تطبيقات كثيرة، فهذا هو القرار الصحيح. اختيار PyPy ليس موقفاً أخلاقياً بشأن تنوع تطبيقات Python؛ بل قرار يتعلق بعبء العمل والصيانة.

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

وإذا كان الهدف هو السرعة الخام، فقارن التطبيق الفعلي بالخيارات المتاحة. قد يساعد مترجم PyPy الفوري في أعباء العمل الطويلة التي تهيمن عليها Python، لكن المكتبات الأصلية، والإدخال والإخراج، والتسلسل، والبدء، والذاكرة قد تكون هي العامل المسيطر. وقد يقدم نشر CPython محسن بعناية، أو خوارزمية مختلفة، أو امتداد مترجم، أو تغيير في بنية العمليات قيمة أكبر. المقارنة الصحيحة هي البرنامج كله، لا حلقة تركيبية.

الحكم النهائي

PyPy 8.0 إصدار مهم مفتوح المصدر لأنه يهاجم عائقاً حقيقياً أمام التبني. يقرب دعم Python 3.12 التجريبي المشروع من منظومة اللغة الحالية. وينقل اعتماد glibc 2.28 ثنائيات Linux إلى خط أساس حديث للتوزيع. وقد يقلل نموذج الكائنات الجديد ودعم cp312-abi3 المخطط له عدد الحزم التي تحتاج إلى بناءات منفصلة لـ PyPy.

لكن الملاحظة المقابلة لا تقل أهمية: لا يكتمل التوافق حتى تختار المثبتات العجلات، وتقبلها آلية التحميل، وتنجو التطبيقات من أعباء العمل الحقيقية. وما تزال المشكلات القديمة المتعلقة بامتدادات C الخاصة بـ CPython، وافتراضات عدّ المراجع، والتبعيات الثنائية، وتفاوت تغطية الاختبارات قائمة. يحسن PyPy 8.0 نقطة البداية؛ لكنه لا يلغي رسم التبعيات.

بالنسبة إلى المطورين، التوصية العملية هي تجربة PyPy 8.0 على عبء عمل محدود واحد مع ملف قفل ثابت ومقارنة مع CPython. أضفه إلى التكامل المستمر إذا كانت مكتبتك تدعي دعم المفسرات البديلة. افحص خط أساس glibc، وتحقق من قيم الأرشيف، واختبر شهادات HTTPS، وافحص كل تبعية أصلية. تعامل مع دعم Python 3.12 على أنه تجريبي، ومع توافق cp312-abi3 على أنه مشروع منظومة ما يزال قيد التنفيذ.

هذا كافٍ لجعل الإصدار جديراً بالتجربة. فلم تكن أقوى حجة لـ PyPy أن كل برنامج Python يجب أن ينتقل إليه. بل إن منظومة Python ينبغي أن تمتلك أكثر من تنفيذ جاد، وأن يكون اختيار أحدها ممكناً من دون تحويل التغليف المعتاد إلى مشروع هندسي منفصل. يدفع PyPy 8.0 هذا الهدف إلى الأمام، لكن الخطوة التالية تعتمد على مشرفي المكتبات وأدوات التغليف بقدر اعتمادها على فريق المفسر.

المصادر

استندت المعالجة إلى مذكرة إصدار PyPy 8.0.0، وصفحات التنزيل وقيم التحقق الخاصة بالمشروع، ومستودع PyPy، ومواصفات وسوم التوافق في دليل مستخدم تغليف Python، وإرشادات تغليف الامتدادات الثنائية، ووثائق Cython الخاصة بنقل الشيفرة إلى PyPy، ودليل PyO3 للبناء والتوزيع، إضافة إلى نقاش الإصدار المشار إليه في المصدر الأصلي.