Requests: لماذا الافتراضي إلى Simplejson؟

شكرا على هذا التقرير! الرجاء مراجعة الإصدار رقم 2516 لآخر مرة تمت فيها مناقشة هذا الأمر.

لكي أكون واضحًا ، أنا الآن كما كنت منفتحًا في ذلك الوقت لإزالة simplejson كخيار تمامًا ، لكن @ kennethreitz أراد ذلك هناك. =)

أنا لا أقول أنه يجب إزالته ... ولكن ربما توجد طريقة أفضل للتحكم في الاستيراد. من الممكن أن تتعارض المكتبات مع بعضها البعض. هل يمكن أن تكون هناك طريقة لتحديد مكتبة json للطلبات؟

من الناحية التاريخية ، كان لدي انطباع بأن simplejson الذي تم تجميعه حديثًا يتمتع بخصائص أداء أفضل من الوحدة النمطية json المضمنة في Python 2.6.

أعتقد أنه لم يتم تمكين "عمليات التسريع" في الوحدة json حتى 2.7.

أذكر من الذاكرة هنا ، لذا قد لا أكون على صواب.

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

توضح التعليقات الثلاثة الأخيرة هنا موقفنا بشكل جيد https://github.com/kennethreitz/requests/pull/2516#issuecomment -89005463

إذن ما الذي تقترح فعله عندما تتعارض مكتبتان مع بعضهما البعض؟ Monkey تصحيح مكتبة الطلبات للتحكم في استيراد json المستخدم؟

الصراع مع بعضنا البعض؟ أنا لا أفهم. إذا كان Simplejson لا يعمل بشكل صحيح على نظامك ، فمن المحتمل أن تكتشف السبب أو تقوم بإلغاء تثبيته.

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

قبل خمس سنوات ، اهتم الناس بسرعة مكتبات تسلسل التشفير / فك التشفير الخاصة بهم أكثر مما يبدو عليهم اليوم. كانت هذه أفضل ممارسة. لا أعتقد أنه ضار أيضًا.

وتجدر الإشارة أيضًا إلى أن 2.6 يتم استخدامه اليوم أقل بكثير مما كان عليه قبل خمس سنوات.

digitaldavenyc فإن الطريقة الوحيدة المقبولة للتحكم في تدفق الاستيراد هي دعم متغير بيئة مثل REQUESTS_NO_SIMPLEJSON . هذا لن يحدث.

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

وتجدر الإشارة أيضًا إلى أن دعم json الخاص بنا بسيط جدًا ، وليس ضروريًا بأي حال من الأحوال لاستخدام المكتبة - يمكنك بسهولة json.loads(response.content) (على الرغم من أننا نقوم بالمزيد مع الترميزات ، على ما أعتقد).

هل يمتلك Simplejson بالفعل أي مكاسب في الأداء مقارنة بـ json الأصلي في الإصدارات الأحدث من Python 3.3+؟

ليس لدي فكرة ، أشك في ذلك. لقد قلت على وجه التحديد Python 2.6.

أو json.loads(response.text) . نعم ، من الجيد استخدام طريقة ملائمة ، لكن الطلبات بها الكثير من طرق الراحة التي يتجاوزها الأشخاص في حالات معينة وهذا مثال رائع لحالة واحدة (حيث يكون لديك متطلب آخر في simplejson والذي يجب أن يعمل بشكل مطابق تمامًا لوحدة json للمكتبة القياسية ).

الأسئلة حول أداء simplejson ليست ذات صلة بالطلبات.

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

هل قرأت أيًا من التعليقات التي أدليت بها سابقًا؟

الأسباب المتعلقة بالأداء == Python 2.6.x.

تضمين التغريدة لقد ذكرت للتو أنه لم يعد الكثير من الناس يستخدمون Python 2.6. هل ما زال من الجيد أن يكون لديك ميزة تستحق تضمينها؟

ربما وربما لا. هذا ما افترضته تصريحاتي أعلاه.

على وجه الخصوص https://github.com/kennethreitz/requests/issues/3052#issuecomment -197025994

أتفق معك في أن تضمين دعم simple-json كان رائعًا منذ 3-4 سنوات ، فقد أظهر هذا المستوى من التفكير الذي يجعل الطلبات مكتبة رائعة. لكني أخفق في رؤية قيمة تضمين simple-json المضي قدمًا في الإصدارات المستقبلية. إذا كانت التطبيقات التي تستخدم Python 2.6 فقط هي التي يمكنها الحصول على أي فوائد من استخدام simple-json ، فيبدو أنه من غير المجدي تضمينها لفترة أطول لأن هذا هو أقل إصدار من Python مدعوم حاليًا بالطلبات.

أنا مجرد مستخدم للطلبات ولكن أنتم يا رفاق تحتفظون بالمكتبة ولكم القرار.

أنا موافق. بعض الخيارات هنا:

1. الاحتفاظ بالأشياء كما هي (يفضل دائمًا)
2. إزالة منطق simplejson تمامًا (أعتقد أن هذا سيكون جيدًا)
3. قصر منطق simplejson على 2.6 فقط (غير مثالي ، لكنه سيحد من الآثار الجانبية المحتملة)

أنا أحب 1 الأفضل ، مع "إذا لم يتم كسره ، فلا تقم بإصلاحه!" عقلية فضفاضة جدا. أعلم أن 2 هو ما يفضله @ sigmavirus24 و Lukasa ، وإذا كان الأمر يستحق الجهد (الأدنى) ، فأنا لست ضده إذا كانا من أجله.

أعتقد أن 3 سيكون الخيار الأفضل على الأرجح لأن مستخدمي Python 2.6 ربما لا يزالون يستخدمون simple-json ولا يزال مدعومًا بالطلبات حتى الآن. هل يمكن أن يكون هناك أي مشاكل مع ذلك؟

لا أعتقد أن أي شخص إما أن يلاحظ أو يهتم. أضعها في _ for_ لهم لأن _I_ اهتممت أكثر مما فعلوا :)

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

موجود على الإنترنت:

باستخدام simplejson (عند استخدام وحدة تسريع) ، يعتمد نوع السلسلة على قيمتها ، أي أنها تقوم بفك تشفير السلاسل على أنها نوع "str" ​​إذا كانت أحرفها هي ascii فقط ، ولكن على أنها "unicode" بخلاف ذلك ؛ الغريب أنه يقوم دائمًا بفك تشفير السلاسل على أنها unicode (مثل وحدة json القياسية) عند تعطيل عمليات التسريع.

خطأ مبتدئ ، على الرغم من أنه ممارسة شائعة جدًا قبل استخدام python3. فعلت الطلبات هذا لسنوات مقابل Response.content قبل أن أبدأ العمل على دعم Python 3 واضطررت إلى إنشاء خاصية مميزة Response.text لـ unicode (تصميم أفضل بكثير).

أظن أن هذه هي المشكلة التي تواجهها.

بالنظر إلى هذه المعلومات ، 2 سيكون: إزالة منطق simplejson تمامًا.

ربما يكون الرقم 2 هو أفضل طريق يمكن اتباعه على المدى الطويل.

حسنًا ، لقد أقدر ذلك عندما قمت بتضمين simple-json مرة أخرى في عام 2010 إذا كان هذا أي عزاء :-)

هل سيكون من المنطقي إعادة فتح العلاقات العامة الأصلية https://github.com/kennethreitz/requests/pull/2516 ؟

رقم # 2516 تمت إضافة رمز غريب للرجوع إلى simplejson ، والذي لا يمكن أبدًا الوصول إليه (تحتوي جميع إصدارات Python على وحدة json يتم استيرادها بنجاح.

صحيح أن هذا غير منطقي. علاقات عامة جديدة إذن؟

نعم. =)

مع دمج # 3056 ، أغلق هذا.

أنا موافق. بعض الخيارات هنا:

1. الاحتفاظ بالأشياء كما هي (يفضل دائمًا)
2. إزالة منطق simplejson تمامًا (أعتقد أن هذا سيكون جيدًا)
3. قصر منطق simplejson على 2.6 فقط (غير مثالي ، لكنه سيحد من الآثار الجانبية المحتملة)

أنا أحب 1 الأفضل ، مع "إذا لم يتم كسره ، فلا تقم بإصلاحه!" عقلية فضفاضة جدا. أعرف أن 2 هو ما يفضله @ sigmavirus24 و Lukasa ، وإذا كان الأمر يستحق بذل (الحد الأدنى) من الجهد ، فأنا لست ضده إذا كانا من أجله.

ربما يكون الرقم 2 هو أفضل طريق يمكن اتباعه على المدى الطويل.

لدي نفس المشكلة أيضًا ، لكنني غير قادر على إزالة simplejson باستخدام "pip3 uninstall simplejson" ، إذا لم تكن هذه هي الطريقة لإزالته ، فيرجى إخباري بكيفية إزالته

Simplejson هي نفس الوحدة مثل "json" ، ولكنها أكثر حداثة (وربما أسرع)

مرسل من الايفون الخاص بي

في 15 تشرين الثاني (نوفمبر) 2019 ، الساعة 1:45 مساءً ، كتب Bhanu Prakash [email protected] :

أنا موافق. بعض الخيارات هنا:

الاحتفاظ بالأشياء كما هي (يفضل دائمًا)
إزالة منطق simplejson تمامًا (أعتقد أن هذا سيكون جيدًا)
قصر منطق simplejson على 2.6 فقط (غير مثالي ، لكنه سيحد من الآثار الجانبية المحتملة)
أنا أحب 1 الأفضل ، مع "إذا لم يتم كسره ، فلا تقم بإصلاحه!" عقلية فضفاضة جدا. أعرف أن 2 هو ما يفضله @ sigmavirus24 و Lukasa ، وإذا كان الأمر يستحق بذل (الحد الأدنى) من الجهد ، فأنا لست ضده إذا كانا من أجله.

ربما يكون الرقم 2 هو أفضل طريق يمكن اتباعه على المدى الطويل.

لدي نفس المشكلة أيضًا ، لكنني غير قادر على إزالة simplejson باستخدام "pip3 uninstall simplejson" ، إذا لم تكن هذه هي الطريقة لإزالته ، فيرجى إخباري بكيفية إزالته

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

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

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