ما هو إصدار Python (2.4، 2.5، 2.6، 3.0) الذي تقوم بتوحيده لجهود تطوير الإنتاج (ولماذا)؟

Question

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

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

لقد قمنا مؤخرًا بفصل بيئة البناء الخاصة بنا عن التبعيات في بيئة المنتج التجاري ويمكننا استخدام أي إصدار من Python (أو Java) نريده.لقد مر شهر تقريبًا أو نحو ذلك منذ أن قمنا بتوحيد لغة Python 2.6 كأحدث إصدار من لغة Python المتوافق مع الإصدارات السابقة.

لا يعد Python 3.0 خيارًا (في الوقت الحالي) نظرًا لأنه سيتعين علينا ترحيل الكثير من قاعدة التعليمات البرمجية الخاصة بنا لجعل أدوات البناء والتكامل الخاصة بنا تعمل بشكل صحيح مرة أخرى.

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

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

تشكرات!

-ميخائيل

Answer 1

وأنا لن تتخلى عن 2.6 فقط بسبب تحذيرات انتقاص. هذه سوف تختفي مع مرور الوقت. (يمكنك استخدام الخيار -W ignore إلى مترجم Python لمنعهم من طباعتها، على الأقل) ولكن إذا وحدات تحتاج إلى استخدام في الواقع لا تعمل مع بيثون 2.6، التي من شأنها أن تكون سببا مشروعا للبقاء مع 2.5. بايثون 2.5 في استخدام واسع الآن، وربما لن يكون لفترة طويلة قادمة (النظر في كيفية طويلة 2.3 استمرت!)، لذلك حتى لو كنت أذهب مع 2.5، أنك لن تضطر لرفع مستوى لفترة من الوقت.

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

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

Answer 2

ووموحدة شركتي في 2.5. مثلك لا يمكننا جعل التحول إلى 3.0 مليون سبب، ولكن أتمنى كثيرا أننا يمكن نقل ما يصل الى 2.6.

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

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

Answer 3

للي أهم التمسك الثعبان 2.5+ لأنه يدعم رسميا ctypes، التي غيرت العديد من الأنظمة المساعد.

وعلى الرغم من أنك يمكن أن تجد ctypes للعمل مع 2.3 / 2.4، ليست واحدة رسميا لها.

وهكذا اقتراحي سيكون 2.5.

Answer 4

نحن ملتزمون بـ 2.5.2 في الوقت الحالي.تركز مجموعتنا التقنية على Django (ولكن لدينا عشرات الأجزاء والأشياء الأخرى.) لذلك نبقى على مقربة مما يفعلونه.

كان علينا العودة إلى docutils إلى 0.4 حتى يعمل مع epydoc 3.0.1.حتى الآن، لم تكن هذه مشكلة كبيرة، ولكنها قد - في مرحلة ما - تجعلنا نعيد التفكير في استخدامنا لـ epydoc.

تعد الترقية إلى الإصدار 2.6 جزءًا من خطة التطوير لدينا.لدينا ميزانية، لكن ليس لدينا جدول زمني محدد في الوقت الحالي.

وبالمثل، فإن الترقية إلى الإصدار 3.0 هي شيء أذكر الناس به.علينا أن نخصص ميزانية لذلك.لن نقوم بذلك هذا العام إلا إذا قفز Django إلى الإصدار 3.0.قد نفعل ذلك في العام المقبل.

Answer 5

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

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

وبدلا من إطلاق مصدر، والذهاب لمنصة اعتمادا ثنائيات (إلى جانب توزيع المصدر).

وهكذا ما عليك فعله هو أن تقوم بتعريف عدد من دعم وحدة المعالجة المركزية، على سبيل المثال: x86-32، إكس86-64، SPARC

وبعد ذلك أنظمة التشغيل التي: لينكس، ويندوز، وسولاريس، فري

لكل نظام التشغيل الذي دعم عدد من الإصدارات الرئيسية.

والخطوة التالية هي التي تقدمها ثنائيات لجميع من لهم.

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

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