مرحبا يا هبر! أقدم إليكم ترجمة "
نحو مقال
نواة بيثون" للكاتب غليف ليفكويتز (مؤلف إطار العمل الملتوي).
مزيد من التفاصيل - تحت الخفض.
سحر التقليل من المكتبة القياسية
تحت تأثير
خطاب أمبر براون الشهر الماضي في قمة لغة بيثون (في اشارة إلى تقرير مايو الخاص بها "البطاريات قيد التشغيل ، لكنها تتسرب" - تعليق المترجم) ، واصل كريستيان هايمز
عمله لتقليل مكتبة بيثون القياسية وإنشاء اقتراح
PEP 594 لإزالة صراحة شظايا عفا عليها الزمن وغير مدعومة منه.
يعد ظهور PEP 594 ("إزالة البطاريات الميتة من المكتبة القياسية") نبأ سارًا للثوار ، وخاصة أولئك الذين يدعمون المكتبة القياسية وسيكون لديهم الآن واجهة أمامية أصغر. جولة قصيرة في معرض PEP من الوحدات المتقادمة أو القائمة على الإزالة تتحدث عن نفسها (تعد وحدات sunau و xdrlib و chunk وحداتي المفضلة). تحتوي مكتبة Python القياسية على العديد من الوحدات المفيدة ، ومع ذلك ، فهي تتضمن أيضًا مقبرة حقيقية ، نصب شاهق من الشظايا القديمة التي تهدد بدفن مطوريها في أي وقت.
ومع ذلك ، أعتقد أنه قد يتم تنفيذ النهج الخاطئ في هذه الجملة PEP. المكتبة القياسية مدعومة حاليًا بالترادف مع مطوري CPython. بقيت قطعًا كبيرة منه على أمل غامض في أن يستفيد أحدًا في يوم من الأيام. في PEP السالف الذكر ، يمكن ملاحظة هذا المبدأ عند حماية وحدة الألوان. لماذا لا إزالته؟ الإجابة: "هذه الوحدة مطلوبة لتحويل ألوان CSS بين أنظمة الإحداثيات (RGB ، YIQ ، HSL و HSV). [إنه] لا يفرض تكاليف إضافية على التطوير الأساسي. "
كانت هناك أوقات كان فيها الوصول إلى الإنترنت محدودًا ، وربما كان من الجيد تحميل Python مسبقًا مع الكثير من المواد ، ولكن في الوقت الحاضر ، تعد الوحدات اللازمة لتحويل الألوان بين أنظمة الإحداثيات المختلفة على بعد خطوة واحدة من أمر pip install.
لماذا لم تفكر في طلب المسبح الخاص بي؟
لذلك ، دعونا نلقي نظرة على هذا البيان: هل تفرض الوحدات الصغيرة مثل الألوان "تكلفة إضافية على التطوير الأساسي"؟
يكفي للمطورين الرئيسيين أنهم يحاولون الحفاظ على قاعدة ضخمة وقديمة لكود C ، وهو CPython نفسه. كما قالت ماريتا فيجيا في
خطابها في نورث باي بيثون ، فإن السؤال الأكثر شيوعًا الذي يطرحه مطورو برامج kernel هو: "لماذا لم تنظر إلى طلب تجميعي؟" وما هو الجواب؟
من الأسهل تجاهل طلبات التجميع هذه. هذا ما يعنيه أن تكون مطور برامج kernel!
قد يتساءل المرء ، هل لدى Twisted نفس المشكلة؟ الملتوية هي أيضًا مجموعة كبيرة من الوحدات المزدوجة ؛ نوع من المكتبات القياسية للتواصل. هل كل هؤلاء العملاء والخوادم لـ SSH ، IMAP ، HTTP ، TLS ، إلخ. إلخ تحاول الضغط على كل شيء في حزمة واحدة؟
أجبر على الإجابة:
نعم . الملتوية متجانسة لأنها تأتي من نفس الفترة التاريخية لـ CPython ، عندما كان تثبيت المكونات معقدًا للغاية. لذلك ، أنا أتعاطف مع موقف CPython.
من الناحية المثالية ، في مرحلة ما ، يجب أن يصبح كل مشروع فرعي في Twisted مشروعًا منفصلًا به مستودعه الخاص ، والتكامل المستمر (CI) ، والموقع الإلكتروني ، وبالطبع مع مطوريه الأكثر تركيزًا. نحن بالفعل نشارك ببطء ولكن بثبات المشاريع التي يمكن رسم الحدود الطبيعية فيها. بعض النقاط التي بدأت في Twisted باستمرار وبشكل تدريجي مفصولة ومؤجلة و filepath في طور الانفصال. مشاريع أخرى ، مثل كلاين وتريك ، تواصل العيش بشكل منفصل. سنفعل المزيد عندما نكتشف كيفية خفض تكاليف إنشاء ودعم التكامل المستمر وكيفية إطلاق البنية التحتية لكل منها.
ولكن هل الطبيعة المتجانسة لـ Twisted هي المشكلة الأكثر إلحاحًا أو حتى الخطورة في المشروع؟ دعونا نقدر ذلك.
في وقت كتابة هذا التقرير ، كان لدى Twisted 5 طلبات معلقة لم يتم حلها في قائمة الانتظار. متوسط الوقت الذي يقضيه في دراسة التذكرة ، أربعة أيام ونصف تقريبًا. يرجع تاريخ أقدم تذكرة في قائمة الانتظار إلى 22 أبريل ، مما يعني أنه قد مضى أقل من شهرين على إرسال أقدم طلب مجمع لم تتم مراجعته.
من الصعب دائمًا العثور على عدد كافٍ من المطورين والوقت للاستجابة لطلبات التجميع. يبدو أحيانًا أننا لا نزال نطرح السؤال "لماذا لا تفكر في طلب البلياردو الخاص بي؟" نحن لا نفعل ذلك دائمًا بشكل مثالي ، لكن بشكل عام نديره ؛ يتقلب قائمة الانتظار بين 0 و 25 أو نحو ذلك في الشهر الأكثر سيئ الحظ.
ماذا عن جوهر CPython مقارنة بهذه الأرقام؟
بعد
زيارة جيثب ، يمكنك أن ترى أن 429 تذكرة تنتظر النظر فيها في الوقت الحالي. ومن المتوقع أن أقدمهم من 2 فبراير 2018 ، أي ما يقرب من 500 يوم.
كم من المشاكل مع المترجم وكم من المشاكل مع مكتبة stdlib؟ من الواضح أن المراجعة المعلقة مشكلة ، لكن هل ستعمل إزالة stdlib على المساعدة؟
للحصول على تقييم سريع وغير علمي ، نظرت إلى أول (أقدم) صفحة من طلبات التجميع. في تقديري الشخصي ، من بين 25 طلبًا تجمع ، تم إرفاق 14 مع المكتبة القياسية ، و 10 مع جوهر اللغة أو رمز المترجم ، وكان واحد يرتبط مع مشكلة وثائق صغيرة. على أساس هذه النسبة ، أود أن أقترح أن هناك ما يقرب من نصف طلبات التجميع التي لم تتم مراجعتها مرتبطة برمز المكتبة القياسي.
لذا ، فإن السبب الأول وراء حاجة فريق CPython الرئيسي إلى التوقف عن دعم المكتبة القياسية هو
أنه ليس لديهم حرفيًا القدرة المادية لدعم المكتبة القياسية. أو بعبارة أخرى ، إنهم
لا يدعمونها ، ويبقى فقط الاعتراف بذلك والبدء في مشاركة العمل.
إنها حقيقة أن أيا من طلبات تجمع مفتوحة CPython ترتبط مع وحدة الألوان. في الواقع ، فإنه لا يفرض تكاليف على تطوير النواة.
تطوير Kernel نفسه يفرض هذه التكاليف. إذا كنت أرغب في تحديث وحدة colorys للحفاظ على تحديثها (ربما للحصول على كائن Color ، وربما لدعم نماذج ألوان عدد صحيح) ، فمن المرجح أنني سأنتظر 500 يوم أو أكثر.
نتيجة لكل هذا ، يكون تغيير الرمز في المكتبة القياسية أكثر صعوبة ، مما يؤدي إلى تقليل اهتمام المستخدمين بالمساهمة. كما تعمل الإصدارات النادرة من CPython على إبطاء عملية تطوير المكتبة وتقليل فوائد تعليقات المستخدمين. ليس من قبيل الصدفة أن تكون جميع وحدات المكتبة القياسية تقريبًا تدعم بنشاط بدائل الطرف الثالث ، وهذا ليس خطأ مطوري stdlib. يتم شحذ العملية بأكملها لركود جميع وحدات stdlib الأكثر استخدامًا.
بيئات جديدة ، متطلبات جديدة
ربما الأهم من ذلك هو أن ربط CPython بالمكتبة القياسية يضع CPython نفسه في وضع متميز مقارنة بالتطبيقات اللغوية الأخرى.
يخبرنا
البودكاست بعد
البودكاست ،
البودكاست بعد
التقرير ، أنه من أجل مواصلة النجاح وتطوير بيثون ، تحتاج إلى النمو في مجالات جديدة: خاصة في الواجهة الأمامية ، وكذلك عملاء الأجهزة المحمولة والأنظمة المدمجة وألعاب التحكم.
تتطلب هذه البيئات شرطًا واحدًا أو اثنين:
في جميع هذه الحالات ، يكون حجر العثرة هو تعريف الوحدات التي يجب إزالتها من المكتبة القياسية. يجب العثور عليها بواسطة التجربة والخطأ ؛ أولاً وقبل كل شيء ،
تختلف العملية تمامًا عن عملية تحديد التبعية القياسية في تطبيق Python. لا يوجد أي إعلان install_requires في setup.py يشير إلى أن المكتبة تستخدم وحدة نمطية من stdlib والتي قد يتخطاها وقت تشغيل Python المستهدف بسبب قيود المساحة.
يمكن أن تحدث مشكلة حتى لو كان كل شيء نستخدمه هو Python القياسي على تثبيت Linux. حتى توزيعات Linux للخوادم وأجهزة الكمبيوتر المكتبية لها نفس الحاجة إلى حزمة Python kernel الأصغر ، لذلك تم اقتطاع المكتبة القياسية بها بالفعل. قد لا يفي هذا بمتطلبات رمز Python ونتيجة لذلك ، قد يؤدي ذلك إلى حدوث أخطاء عندما
لا يعمل تثبيت النقطة .
أعتبر كل شيء بعيدًا
"ماذا عن الافتراض الذي تحتاجه للتنظيف قليلاً كل يوم؟ على الرغم من أنها تبدو مقنعة ، لا تدع نفسك يخدع. السبب الذي يجعلك تبدو أن التنظيف لا ينتهي أبدًا هو أنك تنظف قليلاً. [...] سر النجاح الرئيسي هو: إذا قمت بإزالته في ضربة واحدة ، وليس تدريجياً ، فيمكنك دائمًا تغيير تفكيرك وعاداتك في الحياة "
ماري كوندو ، التنظيف السحري. الفن الياباني لاستعادة النظام في المنزل وفي الحياة "(ص 15-16)
في حين أن الخفض التدريجي للمكتبة القياسية يعد خطوة في الاتجاه الصحيح ، فإن التغييرات التدريجية وحدها لا تكفي. كما تقول ماري كوندو ، إذا كنت تريد حقًا ترتيب الأمور ، فإن الخطوة الأولى هي
الحصول على كل شيء بعيدًا عن الأنظار من أجل رؤية كل شيء حقًا ، ثم إرجاع ما هو مطلوب فقط.
لقد حان الوقت للإشادة بتلك الوحدات التي لم تعد مشجعة ، وإرسالها بعيدًا.
نحتاج إلى إصدار من Python يحتوي على الحد الأدنى الضروري فقط بحيث يمكن أن تكون جميع التطبيقات متسقة ، وبحيث يمكن للتطبيقات (حتى تلك التي تعمل في متصفحات الويب أو المتحكمات الدقيقة) أن تحدد متطلباتها ببساطة في requirements.txt.
في بعض بيئات العمل ، تبدو فكرة وجود مكتبة قياسية ضخمة جذابة لأن إضافة التبعيات في requirements.txt تعتبر بيروقراطية ، ومع ذلك ، فإن "المكتبة القياسية" في مثل هذه البيئات لها حدود تعسفية بحتة.
قد لا تزال فكرة جيدة لتزويد بعض توزيعات CPython الثنائية (ربما حتى الرسمية منها) بمجموعة واسعة من الوحدات من PyPI. في الواقع ، حتى بالنسبة للمهام العادية ، هناك حاجة إلى قدر معين من مكتبة stdlib ، والتي تحتاج إلى تثبيت pip وحدات أخرى ضرورية.
يوجد الآن موقف حيث يتم توزيع pip مع Python ، لكن
لم يتم
تطويرها في مستودع CPython. تم تطوير جزء مما يأتي عليه برنامج تثبيت Python الافتراضي في مستودع CPython ، ويأتي جزء منه في لعبة tarball منفصلة للمترجم الفوري.
لاستخدام Linux ، نحتاج إلى وسائط قابلة للتمهيد مع مجموعة كبيرة من البرامج الإضافية. ولكن هذا لا يعني أن نواة Linux نفسها موجودة في مستودع عملاق واحد ، حيث يتم تطوير مئات التطبيقات اللازمة لخادم Linux يعمل بواسطة فريق واحد. يعتبر Linux kernel ذا قيمة عالية ، لكن أنظمة التشغيل التي تستخدمه يتم إنشاؤها من خلال
مجموعة من Linux kernel ومجموعة واسعة من المكتبات والبرامج المطورة بشكل منفصل.
استنتاج
كانت فلسفة "تضمين البطاريات" مناسبة تمامًا لإنشائها ؛ مثل صاروخ الداعم ، سلمت بيثون للجمهور البرمجة. ومع ذلك ، مع نضوج النظم الإيكولوجية مفتوحة المصدر وحزم Python ، تصبح هذه الاستراتيجية قديمة ، ومثل أي مسرع ، يجب أن ندعها تعود إلى الأرض حتى لا تعيدنا إلى الوراء.
توفر أوقات تشغيل Python الجديدة ومهام النشر الجديدة وجمهور المطورين الجدد لمجتمع Python فرصًا هائلة للوصول إلى آفاق جديدة.
ولكن لتحقيق ذلك ، نحن بحاجة إلى نواة بيثون جديدة أكثر إحكاما وغير مثقلة. نحتاج إلى هز المكتبة القياسية بأكملها على الأرض ، مع ترك الأجزاء الأصغر التي نحتاجها فقط حتى نتمكن من القول: هذا أمر ضروري حقًا ، لكن من الجيد أن يكون لدينا.
آمل أن أقنعت بعضكم على الأقل بيثون الذي نحتاج إليه.
والآن: من يريد أن يكتب
PEP ؟