Requests: ضع في اعتبارك تضمين الطلبات في مكتبة Python 3.5 القياسية

نعم ، لأنه يبسط العملية برمتها ولا يضحي بالأداء. لذا نعم.

• ما نوع تأثير ذلك على قدرة الطلبات على التطور والنمو؟
• هل يتوافق تردد إصدار الطلبات مع تردد بيثون؟ قد يكون الاختلاف الكبير هنا مؤشرًا جيدًا على أن stdlib ليس المكان المناسب للطلبات.

لننشر بعض الأشخاص الذين نهتم بشدة بآرائهم:

shazowkevinburkedstufftalex @ sigmavirus24

ماذا حدث لـ "القانون المعياري هو المكان الذي تموت فيه الأشياء"؟

سؤال إيقاع التحرير سؤال جيد. سأكون قلقًا بشأن فقدان قدرة الطلب على التطور بحرية. ومع ذلك ، ربما تكون مكتبة الطلبات الأساسية مناسبة تمامًا.

قيمة 2 $ CURRENCY الخاصة بي:

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

أعتقد أن الحقيقة هي أنه إذا دخلت هذه الوحدة إلى المكتبة القياسية ، فسينتقل الفريق الأساسي الحالي منها. أنا بالتأكيد لدي القليل من الاهتمام بمتابعته في المستنقع الذي يمثل التطوير الأساسي. من المرجح أن تكون الطلبات المضيفة في stdlib هي @ sigmavirus24 ، وهو مجرد رجل واحد. سيؤدي فقدان الاتجاه هذا حتمًا إلى تآكل واجهة المكتبة بمرور الوقت ، وأعتقد أن هذا سيكون شيئًا مأساويًا.

الشيء الوحيد الذي يمنحنا إياه التواجد في المكتبة القياسية هو وقتنا السابق. هذا سبب وجيه لوضعه هناك ، إذا كان هذا هو ما تعتقد أنه يحتاج إليه ، لكن لا أعتقد أنه يجب علينا التظاهر بأنه سيجعل المكتبة أو نظام Python البيئي أفضل.

لا أعتقد أنك في الواقع _can_ تضيف طلبات إلى stdlib دون إضافة chardet و urllib3 أولاً أو إزالة اعتمادك عليها. هناك أيضًا الشيء الذي لا تريد Python فيه شحن CA Bundle ، لذا ستحتاج إلى تعديلها بحيث تستخدم حزمة النظام الأساسي كما تفعل Python الآن بشكل طبيعي.

إلى جانب ذلك ، لست متأكدًا. من المؤكد أنه سيسهل الحصول على الطلبات ، ولكن جزءًا من عملي على النقطة هو في الأساس جعل الأمر سهلًا ، لذا من السهل الحصول على أشياء مثل الطلبات دون الحاجة إلى إضافتها إلى stdlib. علاوة على ذلك ، من المربك إلى حد ما أن يكون لديك طرق متعددة لإجراء طلبات HTTP في Python stdlib. كان توحيد urllib و urllib2 أمرًا جيدًا في Python stdlib ولا أعتقد أن إعادة إضافة ذلك باستخدام urllib.request و "الطلبات" فكرة جيدة أيضًا. أخيرًا ، لا أعتقد أنه سيساعد بالفعل العديد من الأشخاص ، فهذا سيذهب فقط إلى 3.5+ لذلك يجب على أي شخص يريد استخدام الطلبات إما استخدام الإصدار الموجود على PyPI أو إنشاء 3.5 الحد الأدنى من إصدار Python المدعوم الذي لا أفعله. أعتقد أنه شيء واقعي سيحدث في المستقبل القريب.

بينما أعتقد أن وجود طلبات في المكتبة القياسية سيساعد المستخدمين الجدد ، لا أعرف أنه سيساعد مجتمع Python ككل. يعرف المستخدمون المتمرسون استخدام الطلبات ومعرفة كيفية تثبيتها.

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

ماذا عن الحل الوسط لجعل توزيعات بايثون مثبتة بشكل افتراضي؟

لا لن تفعل ذلك.

الطلبات غير مناسبة تمامًا لتضمين stdlib للعديد من الأسباب المذكورة قبلي. تبعية urllib3 وحدها هي أداة عرض كاملة ؛ لا نريده أن يموت في stdlib.

ما قد يكون مفيدًا هو إضافة شيء _basic_ ومشابه للطلبات المبنية على موارد http الحالية لـ stdlib والتي تتيح للمستخدمين القيام بطلبات الحصول / النشر البسيطة على https دون ممارسة سحر الدم.

تذكير أيضًا بأنه سيتم إضافته إلى Python 3 فقط. :) (وليس قبل بايثون 3.6).

هل سئمت من الحفاظ عليها يا كينيث؟ ؛)

لا أعتقد أنه يمكننا حتى البدء في مناقشة هذا السؤال دون أن يقول شخص ما ما سيحدث لـ HTplib و urllib والأصدقاء. أعتقد أن إضافة الطلبات دون معالجة تعقيد الاختيار هو أسوأ من الإجابة "تجاهل teh stdlib ، فقط استخدم الطلبات". إنه انحدار إلى أيام urllib ، urllib2.

أعتقد أن الحقيقة هي أنه إذا دخلت هذه الوحدة إلى المكتبة القياسية ، فسينتقل الفريق الأساسي الحالي منها. أنا بالتأكيد لدي القليل من الاهتمام بمتابعته في المستنقع الذي يمثل التطوير الأساسي. من المرجح أن تكون الطلبات المضيفة في stdlib هي @ sigmavirus24 ، وهو مجرد رجل واحد. سيؤدي فقدان الاتجاه هذا حتمًا إلى تآكل واجهة المكتبة بمرور الوقت ، وأعتقد أن هذا سيكون شيئًا مأساويًا.

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

من المحتمل أن ينتهي بي الأمر فقط بتقديم طلبات لمواصلة استخدامه.

الطلبات غير مناسبة تمامًا لتضمين stdlib للعديد من الأسباب المذكورة قبلي. تبعية urllib3 وحدها هي أداة عرض كاملة ؛ لا نريده أن يموت في stdlib.

لطالما كان خلافًا لدى @ kennethreitz (وبالتالي ، المشروع ككل) أن urllib3 هو أحد تفاصيل التنفيذ. يتم التعامل مع العديد من أكبر ميزات الطلبات بالكامل بواسطة urllib3 ، لكن هذا لا يعني أنه لا يمكن إعادة تنفيذها بعناية في مكتبة لا تعتمد على التبعية حقًا.

فيما يتعلق بالاعتماد على Chardet: لم يكن سوى صداع لنا (وبالنسبة لي على وجه التحديد). اعتاد أن يكون له قواعد أكواد منفصلة لـ py2 و py3 حتى حصلت عليه في مكتبة قاعدة بيانات واحدة (والتي تم دمجها في الأشهر القليلة الماضية فقط في chardet المناسب). المكتبة بطيئة وخنازير ذاكرة ضخمة (مما يثير غضب الكثير من الناس لدرجة أنهم يصرخون علينا هنا حول أداة تعقب المشكلة). إنه ليس دقيقًا تمامًا وقد تم التخلي عن مجموعة Mozilla العالمية التي تم تصميمها بعد ذلك ولكن تم التخلي عنها من قبل Mozilla. لذا فمن المحتمل أن تكون إزالة الحرف على أي حال من الأحوال صافيًا إيجابيًا.

فيما يتعلق بما إذا كان ينبغي أن نفعل هذا أم لا ، فأنا بصراحة غير مبال. كل ما سيكون في stdlib سينتهي به الأمر إلى أن يكون طلبات في API فقط. معدل اعتماد Python 3 بطيء بما يكفي لدرجة أنني لا أعتقد أن الناس سيتأثرون بشكل كبير بهذا خلال السنوات N القادمة (حيث N هو عدد السنوات غير المعروف عالميًا لـ 3.5 لاستخدامه في الإنتاج من قبل الشركات).

وكما قلت ، ربما ينتهي بي الأمر فقط بتقديم الطلبات أو استخدام urllib3 مباشرة في تلك المرحلة.

لقد ناقشت هذا بإسهاب مع Guido في ذلك اليوم - كان لابد من إدراج Chardet أولاً. أعتقد أنه يمكن تضمين urllib3 والطلبات في حزمة http معًا.

ومع ذلك ، فأنا أميل إلى الاتفاق مع hynek و @ dstufft. ربما الطلبات جيدة كما هي :)

في كلتا الحالتين ، إذا كان لديك رأي ترغب في مشاركته ، فنحن نرحب بك لمشاركته هنا (أو في أي وقت حقًا).

: بريق:: كيك:: بريق:

أيضًا ، يبدو أن إضافة وحدة http جديدة إلى stdlib بدون قصة غير متزامنة
مجنون لي.

يوم الأحد 25 كانون الثاني (يناير) 2015 الساعة 1:15:51 مساءً Kenneth Reitz [email protected]
كتب:

في كلتا الحالتين ، إذا كان لديك رأي تود مشاركته ، فأنت كذلك
مرحبًا بكم لمشاركتها هنا (أو في أي وقت حقًا).

[الصورة:: البريق:] [الصورة:: كعكة:] [الصورة:: التألق:]

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

لا أعتقد أنه يمكننا حتى البدء في مناقشة هذا السؤال دون أن يقول شخص ما ما سيحدث لـ HTplib و urllib والأصدقاء

هذه هي مشكلتي. أعتقد أن الوضع الحالي المربك يجب تسويته أولاً.

: +1:: معدن:

فقط لكي أكون واضحًا ، لا ينبغي الاستخفاف بتعليقي أعلاه حول إعادة تنفيذ urllib3 لتضمينه في stdlib. سيكون حجم العمل اللازم للقيام بذلك هائلاً لأن urllib3 هو نتاج (من المحتمل 10 سنوات أو أكثر) من عمل المطور.

لقد تحدثت أيضًا مع Guido حول رمي urllib3 في stdlib منذ بضع سنوات مع استنتاج مفاده أنها ليست فكرة رائعة ، لكنني محايد إلى حد ما حيال ذلك في هذه المرحلة.

كانت واجهة برمجة تطبيقات urllib3 في الغالب مستقرة ومتوافقة تمامًا مع الإصدارات السابقة لعدة سنوات حتى الآن. من المحتمل أن تكون وتيرتها أبطأ من تلك الخاصة بـ stdlib اليوم ، مع كون الغالبية العظمى من التغييرات عبارة عن إصلاحات طفيفة أو تحسينات أمنية (مع إضافات الميزات المتوافقة مع الإصدارات السابقة مثل المهلات / عمليات إعادة المحاولة). إذا أراد شخص ما حقًا محاولة إدخال urllib3 في المكتبة القياسية ، فلا أعتقد أنها فكرة رهيبة - إنها ليست مجرد فكرة _ أفضل_.

(أنا لا أتحدث عن الطلبات ، لأنها تتحرك بوتيرة مختلفة جدًا بأهداف مختلفة عن urllib3.)

أفضل فكرة ، في رأيي ، هي أن يقوم PSF بتوظيف (أو ربما Kickstart أو أي شيء آخر) لبناء مكتبة http جديدة تمامًا بالإضافة إلى دعم HTTP / 2 مع إلهام كبير من طلبات urllib3 و hyper. يسعدني أن أرى أكبر قدر ممكن من الشفرة مأخوذة حرفيًا ولكن تم وضعها بطريقة متسقة ونمطية وقابلة لإعادة الاستخدام. استهدف Python 4 بشكل مثالي أو شيء من هذا القبيل ، وتخلص من كل urllibs و htplibs. أتوقع أن يكون هذا من 6 إلى 9 أشهر من العمل الشاق ، ولكن ربما أكثر من ذلك.

أسوأ جزء في urllib3 ، والذي أود أن أراه مستبدلاً إذا حاول شخص ما إعادة كتابته وفقًا لاقتراح @ sigmavirus24 ، هو أنه يعتمد علىorrllib. وظائف urllib3 محدودة إلى حد كبير حيث يتم إنفاق الكثير من التعليمات البرمجية في العمل حول أوجه القصور في HTplib. على الرغم من أنه إذا تم أخذ دعم HTTP / 2 على محمل الجد في هذا الهدف ، فإن نطاق إعادة تنفيذ HTTP / 1.1 سيكون جزءًا مريحًا للغاية من العمل المطلوب.

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

+1 @ shazow

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

نعم ، لأن الطريقة الوحيدة التي سأسمح بها مطلقًا بالطلبات باعتبارها تبعية هي إذا كانت في stdlib.

ومع ذلك ، يحتوي urllib3 على الميزات التي يريدها الأشخاص حقًا ، لذا فإن وجود ذلك في stdlib يكفي بالنسبة لي

هل لا تستخدم أي تبعيات؟

dstufft هذا في المشاريع التي لا تفعل ذلك عمومًا ، حيث لا يمكن

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

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

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

إذا انتقلت إلى stdlib ، يجب أن تكون واجهة برمجة التطبيقات مستقرة.

dcramer ، json الذي لا يكسر أي شيء. يمكنك الاستمرار في محاولة اتهامنا بخرق واجهة برمجة التطبيقات كثيرًا ، ولكن عندما يكون لمشاريع مثل OpenStack متطلبات محددة على أنها >=1.2.3 لفترة طويلة ، أعتقد أن هذا يخبرنا كثيرًا عن استقرار الطلبات. كانت واجهة برمجة التطبيقات مستقرة ، على وجه التحديد لأننا بعد قطع 1.0 رفضنا جميع الإضافات الجديدة إلى واجهة برمجة التطبيقات (مع الاستثناء الأخير الواضح المتمثل في إضافة معلمة json ) وكنا صارمين للغاية بشأن عدم كسر واجهة برمجة التطبيقات. إذا لم تكن مستهلكًا للطلبات ، فلن تعرف هذا بالرغم من ذلك. لذلك أنا لا آخذ جهلك على محمل شخصي.

علاوة على ذلك ، إذا كان من المفترض أن تكون واجهة برمجة التطبيقات stdlib مستقرة جدًا ، فشرح سبب كسر argparse بواجهة برمجة التطبيقات العامة بين Python 3.3 و 3.4؟

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

أنت تعلم أن Python تغير واجهة برمجة التطبيقات (API) أيضًا ، غالبًا في الواقع ، أحيانًا بطرق رئيسية جدًا ، ربما سمعت عن Python 3؟

حسنًا ، سأترك هذا النقاش. لقد أوضحت آرائي. لست متأكدًا مما تتهاون بشأنه جميعًا.

أعتقد أن بعض الأسئلة الرئيسية التي يجب الإجابة عليها هي:

1. كيف تريد تغيير الوثائق القياسية (بما في ذلك البرنامج التعليمي)؟ يرجع تاريخ واجهات برمجة تطبيقات HTTP الخاصة بالمكتبة القياسية الحالية إلى عصر كان فيه استبعاد تفاصيل البروتوكولات المنافسة (مثل FTP مقابل HTTP) يعتبر نهجًا مرغوبًا فيه. في العقد ونصف العقد اللاحقين ، تقارب مجتمع تطوير الويب على HTTPS + JSON باعتباره النهج المفضل لتفاعل العميل / الخادم على نمط الطلب / الاستجابة لمعظم حالات الاستخدام بخلاف تنفيذ الأمر عن بُعد (والذي يستخدم إما SSH أو Windows RCP) ، وطلبات API هي تطبيق العميل القياسي الفعلي لهذا النموذج لتطبيقات Python الحديثة.
2. هل تريد أن تتم ترقية واجهة برمجة التطبيقات للطلبات من معيار بحكم الأمر الواقع إلى معيار قانوني ، بحيث يتم تضمينه تلقائيًا في جميع قنوات إعادة توزيع CPython ، ويتم دعمه بضمانات دعم طويلة الأجل لـ CPython (وموزعينا التجاريين) ، بالإضافة إلى كل الأنشطة التعليمية "المكتبة القياسية فقط"؟ (لا يزال هذا الأخير شائعًا جدًا ، نظرًا لأن معايير الاستخدام في بيئات الشركات غالبًا ما تتضمن الدعم وضمانات IP ، والتي تتوفر لدى CPython ، ولكن الطلبات لا تتوفر. في ظل الوضع الحالي ، لن ينظر العديد من المستخدمين إلى الطلبات كخيار لأنهم إنه عمل كثير جدًا بالنسبة لهم للحصول على اعتماد للاستخدام)
3. ما هي الوحدات النمطية الأخرى في المكتبة القياسية التي يمكن تحسينها من خلال وجود طلبات مثل API للبناء عليها؟
4. هل سيكون من الأفضل الاحتفاظ بالطلبات نفسها دون تغيير كتطبيق مستقل عن الإصدار لواجهة برمجة التطبيقات ، وبدلاً من ذلك إضافة طلبات جديدة مستوحاة من واجهة برمجة التطبيقات إلى المكتبة القياسية ، على غرار الطريقة التي تعامل بها Guido مع عمل توحيد معايير ayncio؟

فيما يتعلق بفكرة أعمال التطوير التي تديرها PSF ، سأعارض ذلك بشدة ، حيث لا توجد لدينا البنية التحتية للإدارة في مكانها المناسب للتعامل مع هذا النوع من الأشياء. اقتراح المنحة الذي يقترح مساهمة PSF في جهد التمويل الجماعي في هذا المجال سيكون قصة مختلفة (لا توجد ضمانات بدون اقتراح محدد للمراجعة ، لكنها بالتأكيد فكرة سنكون قابلين للمناقشة).

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

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

أوه ، هناك سؤال رئيسي آخر يجب الإجابة عليه قبل التطوع للحفاظ على الأشياء في المكتبة القياسية: هل أنت مستعد لقبول مسؤولية برامج الشحن التي تساعد في تشغيل نصف بورصات العالم ، وهي واحدة من أكثر اللغات شيوعًا للبنية التحتية للشركات ، من أكثر اللغات شيوعًا للبرمجة العلمية (بما في ذلك استخدامها لتخطيط المسار في بعثات الفضاء بين الكواكب) ، وهي إحدى اللغات الأكثر شيوعًا لتطوير الويب ، وإحدى اللغات الرئيسية المستخدمة في مبادرات محو الأمية الحاسوبية الجديدة في المؤسسات التعليمية؟

هل أنت مستعد أيضًا للقيام بذلك أثناء وجود أشخاص يعملون في خدمات غير حرجة حيث تكون مستويات الموثوقية المنخفضة جدًا (غالبًا أقل من 99 ٪ من وقت التشغيل) مقبولة تمامًا وتشكو من أن مشكلات الثقة العميقة لديك غير مبررة ، وهي مجرد مسألة سياسات غبية مخبأة لا يمكن أن يتضايقوا من أنفسهم؟

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

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

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

كمثال أكثر واقعية عن كيف يمكن لفقاعة التصفية "مجتمع المصدر المفتوح" أن تحرف وجهة نظرنا: تمتلك Jenkins أكثر من 70٪ من حصة السوق في عمليات نشر CI للشركات.

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

تضمين التغريدة
لست متأكدًا مما تتهاون بشأنه جميعًا.

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

تضمين التغريدة

فيما يتعلق بالنقطة 1: أعتقد أنه سيتم تبسيط الوثائق بشكل كبير مع الطلبات (الطلبات على حد سواء) في stdlib. من أول الأشياء التي أفعلها عند تعلم لغة جديدة هو معرفة كيفية عمل HTTP. إن وجود هذه الميزة هو شيء سيستفيد منه الدليل بغض النظر.

فيما يتعلق بالنقطة الثانية: هناك فرق بين واجهة برمجة التطبيقات والمكتبة كونها بحكم الواقع مقابل بحكم القانون. يمكن بسهولة توفير API بواسطة المكتبة القياسية. أعتقد أن اهتمامك بالدعم سيكون موجهًا بشكل أكبر نحو تضمين الطلبات (الكود).

فيما يتعلق بالنقطتين 3 و 4: لست متأكدًا من أن هذا شيء يجب مناقشته هنا. ربما تكون أفكار الثعبان أفضل.

فيما يتعلق بفكرة أعمال التطوير التي تديرها PSF ، سأعارض ذلك بشدة ، حيث لا توجد لدينا البنية التحتية للإدارة في مكانها المناسب للتعامل مع هذا النوع من الأشياء.

ذلك مثير للاهتمام. لم أكن أعتقد أنه احتمال ولكن سيكون من الرائع أن يكون لديك شيء أفضل من http (lib).

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

لست متأكدًا من النفوذ الذي تتحدث عنه. لقد رأيت ensurepip و venv وأشياء أخرى تم كسرها بواسطة Debian ومُعاد توزيع آخرين في CPython. هذا عرضي لهذه المناقشة رغم ذلك.

أوه ، هناك سؤال رئيسي آخر يجب الإجابة عليه قبل التطوع للحفاظ على الأشياء في المكتبة القياسية: هل أنت مستعد لقبول مسؤولية برامج الشحن التي تساعد في تشغيل نصف بورصات العالم ، وهي واحدة من أكثر اللغات شيوعًا للبنية التحتية للشركات ، من أكثر اللغات شيوعًا للبرمجة العلمية (بما في ذلك استخدامها لتخطيط المسار في بعثات الفضاء بين الكواكب) ، وهي إحدى اللغات الأكثر شيوعًا لتطوير الويب ، وإحدى اللغات الرئيسية المستخدمة في مبادرات محو الأمية الحاسوبية الجديدة في المؤسسات التعليمية؟

كما ذكرنا سابقًا ، لن يستمر معظم الأشخاص المعنيين حاليًا في المشروع. من المحتمل أن أكون الشخص الوحيد ، لكن بالنظر إلى سجلي الحافل في تطوير CPython المنبع ، فلن يكون من المثمر ترك هذا العبء للمطورين الأساسيين الحاليين (والمستقبليين).

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

الحقيقة هي أن هؤلاء الناس لن يلحقوا بالركب أبدًا ، أليس كذلك؟ لا يزال الأشخاص يشغلون البرامج على Python 2.4 و 2.5. لا تزال موازنات تحميل F5 تدعم Python 2.5 فقط. 2.7 سيكون قيد الاستخدام على الأرجح حتى نهاية حياتي الطبيعية (والتي آمل أن تكون طويلة جدًا). هل هؤلاء هم الأشخاص الذين سيؤثر هذا القرار بشدة؟ قد لا يتمكن هؤلاء الأشخاص الذين وصفتهم من تحقيق قفزة إلى Python 3. وفي الوقت الحالي ، لا تزال قفزة كبيرة. ربما بحلول الوقت الذي قرروا فيه التفكير في الأمر ، ستخرج Python 3.8 أو 3.9 أو 4.2 وستكون أقل صعوبة بالنسبة لهم.

حسنًا ، نقطتي الرئيسية هي أن الهدف من تضمين المكتبة القياسي يختلف تمامًا عن هدف المهمة الأكثر شيوعًا المتمثلة في توفير مكتبة مفتوحة المصدر لاستخدامها من قبل مطوري البرامج مفتوحة المصدر الآخرين. إذا اختار فريق الطلبات الاستمرار في تقديم المكتبة التي تتم صيانتها بشكل مستقل فقط (خدمة مجتمعية أنا ممتن للغاية لها ، أنتم أيها الأشخاص تقومون بعمل رائع!) ، ولا تدعمون الضغط من أجل توحيد واجهة برمجة التطبيقات ، فسنعتمد على ذلك على معاد التوزيع مثل RHEL / Fedora / CentOS و Debian / Ubuntu و ActiveState و En Thinkt و Continuum Analytics لالتقاط الوحدة وتوحيدها على أي حال ، بحيث يمكن للناس افتراض أنها ستكون متاحة دائمًا (أو على الأقل في كثير من الأحيان كافية لتكون متاحة لهم) سعيد بالاعتماد على API في نصوص برمجية ذات ملف واحد غير معبأة بالكامل مع إعلانات التبعية المناسبة). ومع ذلك ، من المحتمل أن تستمر معظم الوثائق التمهيدية في توجيه الأشخاص نحو إجراء HTTP بالطريقة القياسية للمكتبة ، لذلك سواء تم تعليم الأشخاص "HTTP for Python ، إصدار 2001" أو "HTTP لـ Python ، إصدار 2015" سيعتمد على ما إذا كانوا يلتقطونه من مصدر "مكتبة قياسية فقط" ، أو مصدر يشتمل على وحدات الطرف الثالث الموصى بها.

كما هو الحال مع virtualenv و PEP 405 ، أو Twisted + Tornado vs asyncio ، أو ipaddr vs ipaddress ، لا أعتقد أنه من المنطقي تضمين _requests نفسها_ في المكتبة القياسية. بدلاً من ذلك ، أعتقد أنه من المنطقي دعم تضمين واجهة برمجة تطبيقات _inspired_ للطلبات التي تتجاهل جميع رموز توافق الإصدارات المتقاطعة ، وحزم الشهادات ، وما إلى ذلك ، وما إلى ذلك ، وتجلب ببساطة واجهات برمجة التطبيقات والوثائق الافتراضية للتعامل مع طلبات HTTP المصادق عليها حتى عام 2015 المعايير. ثم في عام 2030 ، سنشتكي من مدى تقادم تصميم واجهة برمجة التطبيقات _requests_ وفقًا لمعايير 2030 ("HTTP؟ من يستخدم ذلك بعد الآن؟!؟!") ، ولكن هذا جيد ، إنها الطريقة التي تعمل بها هذه الدورات فقط (حتى AJAX الأول ثم جاء JSON ، وكان XML-RPC ملك التل). إذا خرجت من تصميم واجهة برمجة التطبيقات لمدة 5 سنوات قبل أن يبدأ الناس في الشكوى من كونه مؤرخًا ، فأنت تبلي بلاءً حسنًا ، 10 أمر مثير للإعجاب ، و 15 رائعًا حقًا.

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

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

فيما يتعلق بدورات التحديث ، فإن أحد الأشياء الرئيسية التي ينقلها توحيد المعايير الأولية (حتى في Python 3) هو إجماع المجتمع. في ذلك الوقت ، تصبح المكتبات التي تعد "backports" لميزات Python 3 أسهل بكثير في تبرير التجميع مع Python 2. وما زلت شخصياً أرغب في رؤية إصدار السومو من Python 2 الذي يقوم بهذا التجميع بالضبط (unittest2، subprocess32، enum34، contexlib2 ، trollius ، إلخ) ، ولكن هذه معركة سياسية منفصلة تمامًا في حد ذاتها ، خاصة فيما يتعلق بإقناع الناس بأن الفائدة والموارد للحفاظ على توزيع السومو المستقل لإعادة التوزيع حتى عام 2020 متاحة بالفعل.

dcramer أشكرك على إعطائنا وقتك - إنه حقًا موضع تقدير: القلب:

@ sigmavirus24 كل شيء على ما يرام :)

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

بما أن هذا قد يصبح الخيط الفعلي الذي ينظر إليه الناس عندما يقولون
"ما الذي يجب أن نضيفه / نغيره عند التفكير في إضافة طلبات إلى stdlib" ،
أود أن أعطي صيحة أخرى لتحديث التسلسل الهرمي للاستثناءات. أنا
عادة ما يكون لديك سؤالان عند فشل الطلب - أ) ما هي
آثار؟ و ب) هل يمكنني إعادة محاولة الطلب بأمان؟
إن فشل بحث DNS والأنبوب المعطل لهما آثار مختلفة جدًا ،
ولكنه يطلب حاليًا مجموعات على حد سواء باعتبارها ConnectionError. لقد قمت بتفصيل بعض
من العمل المتضمن هنا:
https://gist.github.com/kevinburke/b98e053a4bf9835c67bb

سعيد لمناقشة المزيد مع الأشخاص المهتمين.

كيفن بيرك
الهاتف: 925.271.7005 | twentymilliseconds.com

في الأحد ، 25 يناير 2015 الساعة 8:15 مساءً ، كتب ncoghlan [email protected] :

كمثال أكثر واقعية لكيفية تصفية "مجتمع المصدر المفتوح"
يمكن للفقاعة أن تحرف وجهة نظرنا: تمتلك جينكينز أكثر من 70٪ من حصة السوق
في عمليات نشر CI للشركات.

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW ، أعتقد أن الصياغة على http://docs.python-requests.org/en/latest/dev/philosophy/ ،

Essentially, the standard library is where a library goes to die.
It is appropriate for a module to be included when active 
development is no longer necessary.

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