Numpy: الطلب: استخدم النسخ الدلالية

تم إنشاؤها على ٤ ديسمبر ٢٠١٧  ·  88تعليقات  ·  مصدر: numpy/numpy

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

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

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

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

15 - Discussion

التعليق الأكثر فائدة

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

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

ال 88 كومينتر

هل يمكن اعتبار أن numpy يستخدم الإصدار الدلالي ، ولكن مع 1 رائد؟

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

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

الأخير: NumPy يجب أن يكون تقريبًا في الإصدار 14 الآن. لكنني أقترح اعتماد هذه الاتفاقية للإصدارات المستقبلية فقط.

راجع للشغل: استخدم سلف NumPy ، Numeric ، الإصدار الدلالي ووصل إلى الإصدار 24 على مدار عقد تقريبًا. لا أعرف لماذا تم تغيير هذا في الانتقال إلى NumPy.

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

هل يمكنك إعطاء مثال على ما تقصده بـ "نظام تسمية الإصدار الذي لا يمكن الخلط بينه وبين النسخ الدلالية"؟ باستخدام الأسماء بدلا من الأرقام؟ أنت تستشهد بالإصدار المستند إلى التاريخ ، لكن المخطط الأكثر شيوعًا لهذا الذي رأيته هو المخطط المستخدم من قبل على سبيل المثال Twisted و PyOpenSSL ، وهما حاليًا 17.9.0 و 17.5.0 على التوالي. هذه تبدو وكأنها نسخ شبه معقولة بالنسبة لي ...

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

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

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

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

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

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

كما لاحظ @ eric-wieser و rgommers ، فإن طلبي يكاد يكون مرادفًا لطلب أن يكون "1." الأولي يتم إسقاطها من إصدارات NumPy. بعبارة أخرى ، يستخدم NumPy بالفعل إصدارًا دلاليًا ، على الرغم من أنه ليس نتيجة قرار سياسي ، وبالتالي ربما لم يتم تنفيذه بدقة. ومع ذلك ، فإنه يشير إلى أن NumPy يمكن أن تتبنى الإصدار الدلالي دون أي تغيير تقريبًا في سير عمل التطوير الحالي.

لقد صدمني تعليق من أحد مسؤولي الأنظمة بشكل خاص باعتباره وثيق الصلة بالموضوع: قال إنه لأغراض تحديد الإصدار المراد تثبيته ، فإن أي اصطلاح آخر غير الإصدار الدلالي يكون عديم الفائدة.

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

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

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

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

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

njsmith حسنًا ، دعنا نبتعد عن الفلسفة ونحو الجوانب العملية: ما هو دور أرقام إصدارات البرامج في التواصل بين مطوري البرامج

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

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

khinsen لا تزال الحزمة oldnumeric تعمل بشكل مثالي ، ويمكن للأشخاص تثبيتها باستخدام:

pip install oldnumeric

ربما يكون هذا هو اقتراحك "الثابت numpy" ، حيث تقتصر واجهة numpy على Python / Cython ولا شيء يتغير أبدًا. بالطبع ، كتابة الكود بالرقم القديم أمر غامض للغاية ، لكن لا يمكنك الحصول عليه في كلا الاتجاهين.

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

سؤال: بصفتك مسؤول أنظمة (حتى على جهازك الشخصي فقط) ، هل تتوقع أن تقوم الحزمة بإسقاط طبقة API كاملة من الإصدار 1.8 إلى الإصدار 1.9؟

بالنسبة لأولئك الذين أجابوا بـ "نعم" ، السؤال الثاني: هل يمكنك تسمية أي برنامج آخر غير numpy قام بهذا من قبل؟

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

لكن إسقاط oldnumeric لم يكن أسوأ حدث في تاريخ NumPy الأخير. يذهب هذا الشرف إلى تغيير دلالات النسخ / العرض لبعض العمليات مثل diagonal . الكود الذي يعرض نتائج مختلفة اعتمادًا على إصدار NumPy (تغيير بسيط في رقم الإصدار!) هو كابوس حقيقي.

راجع للشغل ، نظرًا لأنه لا يكاد أحد يعرف القصة: pip install oldnumeric يعمل منذ يومين ، لأن xoviat أعد هذه الحزمة الإضافية ووضعها على PyPI. شكرا جزيلا!

هل تتوقع أن تقوم الحزمة بإسقاط طبقة API كاملة من الإصدار 1.8 إلى الإصدار 1.9؟

إلى أي طبقة تشير؟

هل يمكنك تسمية أي برنامج بخلاف numpy قام بهذا من قبل؟

أسقطت SciPy حزم weave و maxentropy ، وكسر pandas الميزات الرئيسية بانتظام. أنا متأكد من أن هناك العديد من الأمثلة البارزة. تحرير: Python نفسها على سبيل المثال ، راجع https://docs.python.org/3/whatsnew/3.6.html#removed

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

استغرق هذا التغيير حوالي 10 سنوات ، ولا توجد طريقة لإحداث نظام إصدار مختلف فرقًا هنا.

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

إلى أي طبقة تشير؟

دعم رقمي / رقمي أفترض

rgommers آسف ، كان يجب أن أقول "مثال آخر خارج نظام SciPy البيئي".

أيضًا ، لا أشكو من إسقاط الدعم لـ oldnumeric . أنا أشتكي من القيام بذلك دون تغيير في رقم الإصدار الرئيسي.

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

لا تنس أن النظام البيئي SciPy به عدد هائل من المستخدمين غير البارزين الذين لا يتابعون التطورات بنشاط. Python و NumPy هي عناصر بنية أساسية من نفس طبيعة ls و gcc بالنسبة لهم. وغالبًا ما يكون الأمر أقل من ذلك: يستخدمون بعض البرامج التي تتم كتابتها بلغة Python ويصادف أنها تعتمد على NumPy ، وعند تعطلها يتم فقدها تمامًا.

rgommers آسف ، كان يجب أن أقول "مثال آخر خارج نظام SciPy البيئي".

قمت للتو بتحرير ردي برابط إلى ملاحظات إصدار Python ، وهذا خارج نظام SciPy البيئي.

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

ببساطة لن يكون هذا هو الحال. إذا كان لدينا بدلاً من 1.12 ، 1.13 ، 1.14 ، إلخ ، 12.0 ، 13.0 ، 14.0 ، فإن المستخدمين يعتادون على ذلك وسيستخدمون نفس استراتيجية الترقية كما كان من قبل. لن تصبح الغالبية العظمى فجأة أكثر تحفظًا.

لا تنس أن النظام البيئي SciPy به عدد هائل من المستخدمين غير البارزين الذين لا يتابعون التطورات بنشاط. Python و NumPy عبارة عن عناصر بنية أساسية لها نفس طبيعة ls و gcc بالنسبة لهم. وغالبًا ما يكون الأمر أقل من ذلك: يستخدمون بعض البرامج التي تتم كتابتها بلغة Python ويصادف أنها تعتمد على NumPy ، وعند تعطلها يتم فقدها تمامًا.

كلها صحيحة ، وكلها غير قابلة للإصلاح بطريقة سحرية برقم الإصدار. إذا قاموا بتشغيل pip install --upgrade numpy ، فعليهم معرفة ما يفعلونه (وهذا على أي حال لا يظهر حتى رقم الإصدار). إذا كان نظام التعبئة والتغليف الخاص بهم ، فإنهم يرون مشكلة البرنامج التي تعطل عدم وجود مجموعة اختبار مناسبة (أو لم يتم تشغيلها).

سلبيات أخرى لتغيير نظام الإصدار الآن:

  • سنقوم بإجراء تغيير في الإصدار دون تغيير في سياسة الصيانة ، سيكون مربكًا وليس مفيدًا
  • نحن الآن نتبع تقدم Python بشكل أساسي ونفعل نفس الشيء مثل بقية النظام البيئي بأكمله. هذا أمر جيد
  • ربما الأهم من ذلك: أننا سنفقد القدرة على الإشارة إلى تغييرات كبيرة بالفعل. من النوع الذي سنذهب إلى 2.x له ، مثل الإصدار الذي قد يكسر ABI.

مرجع خط الأساس الخاص بي ليس Python ، ولكنه تثبيت برنامج نموذجي. كما قلت ، بالنسبة للعديد (ربما معظم) المستخدمين ، NumPy هي بنية تحتية مثل gnu-coreutils أو دول مجلس التعاون الخليجي. إنهم لا يفسرون أرقام الإصدارات على وجه التحديد في سياق نظام SciPy البيئي.

لقد قمت بفحص سريع لنظام دبيان 9 مع حوالي 300 حزمة مثبتة. 85٪ منهم لديهم رقم إصدار يبدأ بعدد صحيح متبوعًا بنقطة. البادئات الصحيحة الأكثر شيوعًا هي 1 (30٪) و 2 (26٪) و 0 (14٪) و 3 (13٪). إذا تبنت NumPy مخططًا لترقيم الإصدارات يتوافق مع التوقعات الشائعة (أي إصدار دلالي أو تقريب قريب) ، فمن المؤكد أنه سيبرز وسيُعامل بحذر.

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

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

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

وفقًا لتلك المعايير ، لا تتبع NumPy حتى خط بيثون ، لأن التغييرات الوحيدة في الدلالات التي أعرفها في لغة بايثون حدثت من 2 إلى 3.

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

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

بالتأكيد سوف تبرز وسيتم التعامل معها بحذر.

ما زلت أعارض. حتى على Debian ، وهو بالتأكيد ليس "تثبيت برنامج نموذجي" لقاعدة مستخدمينا (سيكون شيئًا مثل Anaconda على Windows). يبدو أيضًا أنك تتجاهل حجتي أعلاه بأن المستخدم لا يمكنه رؤية رقم الإصدار بشكل طبيعي (لا مع pip install --upgrade أو مع مدير الحزم).

أيضًا ، من المحتمل أن تكون تجربتك في عدم تعطل أي شيء آخر أبدًا لأنك تستخدم أشياء مثل أدوات نظام التشغيل وبرامج واجهة المستخدم الرسومية ، وليس سلاسل التبعية الكبيرة الأخرى. على سبيل المثال ، ربما يكون النظام البيئي JavaScript / NodeJS بأكمله أكثر هشاشة من نظام Python.

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

هذا مثال جيد على التفاصيل الدقيقة هنا. بقدر ما أعرف ، MMTK ومشاريعك الأخرى هي الوحيدة التي لا تزال موجودة والتي تأثرت بإزالة كود التوافق الرقمي / الرقمي. كم عدد المستخدمين الذين تعتقد أن لديك؟ 100؟ 1000؟ يحتوي NumPy على الملايين ، لذا ربما تأثر 0.1٪ من مستخدمينا بهذه الإزالة؟ هذا بالتأكيد ليس صفراً ، وحقيقة أنه صغير لا يعني أنه لا يهم - أتمنى أن نتمكن من دعم 100٪ من المستخدمين إلى الأبد بكل الطرق. وأنا أتفهم أنه أمر مؤلم بشكل خاص بالنسبة لك ، تلقي 100٪ من الشكاوى من المستخدمين.

ولكن إذا صدمنا رقم إصدارنا الرئيسي لهذا ، فهذا يعني أن 99.9٪ من مستخدمينا ، لقد بكينا للتو ذئبًا. إنها إيجابية خاطئة. OTOH بالنسبة إلى 0.1٪ من المستخدمين ، كان مهمًا حقًا. ومع ذلك ، فليس من غير المألوف أن نكسر أكثر من 0.1٪ من المستخدمين في الإصدارات الصغيرة ، على الرغم من جهودنا القصوى. إذن ماذا نفعل؟

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

لا أفهم كيف ولماذا يجب أن يقدم مشروع NumPy توصيات عالمية. الناس والمؤسسات لديهم احتياجات مختلفة.

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

يذهب هذا الشرف إلى تغيير دلالات النسخ / العرض لبعض العمليات مثل diagonal .

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

و راجع للشغل ، أنا متأكد تمامًا إذا كنت تبحث في التاريخ العميق ، يمكنك العثور على تغييرات فظيعة أكثر من ذلك :-).

لاحظ أيضًا أن التحديثات الوحيدة في البرامج المثبتة على دبيان والتي أدت إلى تعطل الأشياء بالنسبة لي كانت في نظام SciPy البيئي ، مع استثناء وحيد لتحديث Emacs الذي أحدث تغييرات في الوضع التنظيمي الذي عطّل امتدادًا محليًا لوضع org.

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

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

تعد بادئات رقم الإصدار المنخفض الإجمالية لأن معظم البرامج المستخدمة على نطاق واسع لا تستخدم semver.

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

نعم ، لهذا السبب نحن حذرين للغاية من مثل هذه التغييرات.

هناك بعض الانفصال في وجهات النظر هنا: يبدو أنك تعتقد أننا نغير الأشياء بشكل طوعي طوال الوقت ، لا تهتم بالتوافق مع الإصدارات السابقة ، إلخ. يمكنني احترام ذلك ؛ أنا أفهم أنه يعكس تجربتك. لكن تجربتنا هي أننا نولي اهتمامًا شديدًا لمثل هذه التغييرات ، وأود أن أقول أنه عندما أتحدث إلى المستخدمين ، فإن 5٪ تقريبًا من لديهم وجهة نظرك ، و ~ 95٪ يشعرون أن numpy يقوم بعمل جيد في الاستقرار ، أو أنها تقوم بعمل جيد جدًا ويجب أن تكون أكثر استعدادًا لكسر الأشياء. ربما يمكنك أن تشعر بالراحة في معرفة أنه حتى لو خيبنا آمالنا ، فإننا أيضًا نخيب آمال المجموعة الأخيرة :-).

مع الاستثناء الوحيد لتحديث Emacs

حسنًا ، للخروج عن الموضوع ، يكون هذا بمثابة مثال على الجانب الآخر من الاستقرار. كان Emacs ثابتًا لسنوات بسبب مقاومة Stallman للتغيير ، مما أدى إلى ظهور مفترق xEmacs. ذهب طريقي إلى Emacs -> xEmacs ، للتراجع معه ، -> Vim ؛) التحجر المبكر هو أيضًا سبب توقفي عن استخدام دبيان مرة أخرى في اليوم. بالنسبة لبعض الأشياء ، التغيير ببساطة ليس ضروريًا أو حتى مطلوبًا ، وأتوقع أن هناك أشخاصًا يشغلون إصدارات قديمة من BSD على أجهزة قديمة مخبأة في خزانة. لكني لا أتوقع وجود العديد من هذه الأماكن.

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

أحاول تحديث المشاريع في
https://github.com/ScientificPython. يتطلب تحديث كود بايثون ذلك
استخدم واجهة برمجة تطبيقات C القديمة (وأعني قديم ؛ بعض الوظائف مثل Py_PROTO كانت
من 2000). العلاقات العامة هي بالطبع موضع ترحيب ، لكنني لست متأكدًا مما إذا كان هناك أي شخص
يريدون قضاء وقتهم في ذلك.

المشكلة الأكبر التي أعتقد أنه طرحها هي أن هناك "الكثير
المشاريع "(لا أعرف أين هم بالضبط لأن جميع المشاريع
لقد رأيت دعم Python 3) الذي يحتاج أيضًا إلى التحديث ؛ كيف هذا
تحديد المشاريع التي يتم تخصيص وقت مطور NumPy؟ وأنا أيضا
لا تعتقد أن ادعاءه المركزي غير صالح: يستفيد SciPy كثيرًا من
حقيقة أنه يمكنه ببساطة نسخ ولصق مشاريع فورتران القديمة (مثل
fftpack) مع تعديل بسيط أو بدون تعديل. إذا كان هؤلاء قد كتبوا في القول
"فورتران 2" والمترجمون الجدد فقط قاموا بتجميع "فورتان 3" ، سيكون هناك
كانت قضايا مهمة.

ومع ذلك ، فإن هذه المشكلات ليست في الحقيقة خطأ NumPy. رغم ما لديه
قال ، مع تثبيت NumPy 1.13 ، لا يزال الرقم القديم يجتاز جميع الاختبارات ،
يشير إلى أن NumPy ليس الجاني هنا. منذ واجهة برمجة التطبيقات الرقمية القديمة
أكثر من عقد حرفيًا (ربما يقترب من عقدين!) ، ولا يزال
يعمل على أحدث NumPy ، أعتقد أن واجهة NumPy API مستقرة على الأرجح
كافية.

charris أتفق معك تمامًا في أن "عدم تغيير أي شيء" ليس موقفًا مثمرًا في الحوسبة.

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

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

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

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

أخيرًا ، يبدو أن البعض منكم يعتقد أنني أخوض معركة شخصية حول الكود الخاص بي. قد يفاجئك أن موقفي الشخصي ليس هو الموقف الذي أدافع عنه هنا. موقع الحلويات الخاص بي لمعدل التغيير يقع في مكان ما بين ما هو شائع في مجال عملي وما هو سائد في فريق NumPy. يستخدم معظم أعمالي اليوم Python 3 و NumPy> 1.10. يبلغ عمر MMTK 20 عامًا وأقوم بأشياء كثيرة بشكل مختلف اليوم. غالبًا ما آخذ أجزاء من التعليمات البرمجية من MMTK التي أحتاجها لمشروع معين وأكيفها مع "SciPy الحديث" ، ولكن هذا شيء يمكنني فعله بثقة فقط لأنني كتبت الكود الأصلي.

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

xoviat عدد الاختبارات في oldnumeric صغير للغاية. لن أستنتج كثيرًا من حقيقة أنهم مروا باستخدام NumPy 1.13.

وحدات الامتداد C التي كنت تبحث عنها عمرها 20 عامًا وقد تمت كتابتها لـ Python 1.4. في ذلك الوقت ، كان من بين أكثر الأمثلة تعقيدًا لمجموعات Python-C وفي الواقع شكل التطور المبكر لـ Numeric (pre-NumPy) وحتى CPython نفسه: تم تقديم CObjects (الكبسولات المسبقة) بناءً على احتياجات ScientificPython و MMTK .

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

rgommers أنا لا يمكنه حتى رؤية رقم الإصدار. إنه ببساطة غير صحيح بالنسبة للبيئات التي أراها يستخدمها الناس من حولي. الأشخاص الذين يقررون بشأن التحديثات (الذين ليسوا دائمًا مستخدمين نهائيين) يرونها. إنهم لا يقومون فقط بـ "تثبيت النقطة - ترقية" مرة واحدة في الأسبوع. حتى أنهم سيعتبرون هذا موقفًا مهملاً.

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

ونعم ، NodeJS أسوأ ، أوافق. لحسن الحظ ، يمكنني تجاهلها بسهولة.

تلقيت للتو بريدًا إلكترونيًا من زميل يتابع هذا الموضوع ولكنه لا يجرؤ على المشاركة. مع تشبيه ممتاز:

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

الأمر كله يتعلق بالتحكم في أدوات المرء.

أعدك بأنني لن اقتحم مختبر زميلك أبدًا في منتصف الليل وأقوم بترقية منزلهم. أنا لا أملك حتى بالاكلافا .

الأشخاص الذين يقررون بشأن التحديثات (الذين ليسوا دائمًا مستخدمين نهائيين) يرونها. إنهم لا يقومون فقط بـ "تثبيت النقطة - ترقية" مرة واحدة في الأسبوع. حتى أنهم سيعتبرون هذا موقفًا مهملاً.

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

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

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

وفي حالة واحدة أعرفها ، حتى لماتلاب

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

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

ثانيًا ، يمكننا محاولة وضع عجلات لإصدارات NumPy الأقدم على PyPI إذا لم يكن ذلك يتطلب الكثير من العمل.

بفضل جهود @ matthew-brett ، يبدو أن الوضع الحالي هو أن لدينا عجلات Windows تعود إلى 1.10 ، و MacOS تعود إلى 1.5 (باستثناء 1.7 مفقود ) ، و Linux يعود إلى 1.6 .

يبدو وضع MacOS / Linux معقولًا جدًا. أعتقد أنه يمكننا إعادة ملء المزيد من إصدارات Windows؟ لم يكن OTOH pip install على نظام التشغيل Windows يعمل بدون جهود بطولية ، لذلك لست متأكدًا من وجود جمهور كبير لهذا الغرض. لدينا بالفعل سنتان من القيمة ، وسيزداد ذلك بمرور الوقت.

أيضًا ، في المرة الأخيرة التي قمنا فيها بتحميل عجلات قديمة ، غضب أحد منا لأن سير العمل افترض أنه لا توجد عجلات وكسر التوافق مع الإصدارات السابقة لها :-)

احب ان اسمع تلك القصة

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

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

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

بالنسبة إلى دول مجلس التعاون الخليجي ، وما إلى ذلك ، على سبيل المثال ، لا أعرف الكثير عن تجميع / C ++ ، لقد أزعجني إصدار 4.8 من مجلس التعاون الخليجي أو نحو ذلك لإجباري على اكتشاف كيفية تغيير العلامات بشكل صحيح بسبب بعض ميزات C ++ 11 أو إذا كان متوقعًا ، الأمر الذي يتسبب في ردود فعل متشابهة جدًا على رسائل البريد الإلكتروني التي يبدو أنك تتلقاها حول numpy ، لذلك لست متأكدًا من اختلافها كثيرًا :).

على أي حال ، لا أرغب في مناقشة الكثير هنا ، فأنا أقدر التعليقات حول ما إذا كنا قد نكون سريعين جدًا أو لا نكون حذرين بما يكفي ، ولكن يجب أن أعترف أنني أيضًا لا أرى تمامًا أن تغيير الإصدار الرئيسي سيساعد كثيرًا في ذلك. أنا شخصياً أعتقد أن 1.13 و 1.6 هما على الأقل إصدار رئيسي واحد بعيدًا عن بعضهما البعض ، ولكن لا يوجد إصدار واحد بينهما يمكنني الإشارة إليه والقول: لقد كان ذلك بمثابة انقطاع كبير في التوافق للعديد من المستخدمين.
أتذكر قراءة التعليقات في الكود: "دعنا نفعل هذا في Numpy 2 ربما" ، بالضبط بسبب الخوف من أي كسر على الإطلاق ، مع هذا النهج أخشى أن يتعطل numpy كثيرًا ، وبصراحة أنا فخور بعض الشيء بكوني جزءًا ما بدا لي على الأقل أنه مرحلة أكثر نشاطًا مرة أخرى والتي كانت مطلوبة والتي كانت ستكون صعبة إذا كنا أكثر تحفظًا. (ربما أكون متحيزًا لأنني لا أملك أدنى فكرة عما حدث قبل مجيئي :)).

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

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

إذن بعد المناغاة لفترة طويلة:

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

الأهم: أنا أعرف الإحباط ، لكن هل هناك حل حقيقي لنا؟ هل تعتقد أنه إذا قمنا بزيادة الإصدار الرئيسي بقوة ، فستتلقى رسائل بريد إلكتروني أقل؟

xoviat هل تسأل عن قصة تلقي شكاوى من تحميل عجلات للإصدارات القديمة؟ كان هذا # 7570.

تعريفي المفضل لـ semver (الذي لم يعد بإمكاني العثور على رابط للنشر الأصلي):

  • رئيسي: كسرنا رمز المستخدم عن قصد
  • طفيفة: كسرنا رمز المستخدم عن طريق الصدفة
  • التصحيح: قمنا بتقسيم حلول عمل المستخدم إلى أخطاء الإصدار الثانوي الأخير

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

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

أعتقد أن شيئًا مفقودًا في هذه المحادثة هو أن الإصدارات القديمة من المكتبات متاحة دائمًا (على pypi من المصدر) ، لذلك إذا كان لديك رمز يتطلب إصدارًا قديمًا من python / numpy / matplotlib ، فاستخدم الإصدارات القديمة. بيئات مساحة المستخدم تجعل هذا الأمر غير مروع للغاية بحيث لا يمكن إدارته.

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

njsmith هذا مضحك جدا. IMO # 7570 ليست مشكلة صالحة بالنظر إلى ذلك
امتثل NumPy لمواصفات العديد من العجلة. بشكل عام ، العجلات
يجب تحميلها للإصدارات الأقدم ، بافتراض أن الوقت مجاني. معطى
هذا الوقت ليس مجانيًا ، يمكننا ببساطة ملاحظة أنه يمكن للناس بناء عجلات
للحصول على إصدار محدد من NumPy إذا كانوا يريدون ذلك ؛ تقديم العلاقات العامة إلى
مستودع عجلات numpy-wheel. أم لا.

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

njsmith يتمثل دورك في تشبيه المجهر في دور بائع مجهر

rgommers أنا أفهم أن الحفاظ على NumPy هو عمل روتيني ، وفي الحقيقة

من ناحية أخرى ، أعترف بالتأكيد بوجود مجموعة خاصة جدًا من النظارات ، لكن هذا صحيح بالنسبة لأي شخص آخر في هذه المناقشة. نظارتي هي تلك الخاصة بـ "الحوسبة العلمية التقليدية" ، وهي بيئة عملي. الأساس (التوقع الافتراضي) هو أن التحديثات لا تعطل أي شيء عن قصد. هذه هي سياسة اللغات المعيارية (C ، Fortran) وكذلك مكتبات البنية التحتية (BLAS ، LAPACK ، MPI ، ...). ومع ذلك ، يحدث الابتكار (مثل ATLAS). إذا كنت تعتقد أن هذا متحفظ ، دعني أصف ما تعنيه المحافظة في عالمي: لا تقم أبدًا بتثبيت إصدار من أي شيء ليس عمره عامين على الأقل ، للتأكد من أن معظم الأخطاء معروفة. هذه سياسة شائعة لأجهزة الكمبيوتر العملاقة التي يكون وقتها مكلفًا للغاية ، والتي يصعب التحقق من نتائجها لهذا السبب.

لاحظ أنني لا أقول أن NumPy يجب أن تتبنى توقعاتي الافتراضية العالمية. أنا فقط أقول إنه يجب أن يشير بوضوح إلى أنه مختلف.

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

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

حسنًا ، بصراحة أعتقد أن فكرة "إعادة التطوير الرئيسية" قد تم التخلي عنها إلى حد كبير في الوقت الحالي لأنها تتطلب إما قدرًا أكبر من قوة التطوير ومن ثم قد تخلق نوعًا مختلفًا تمامًا من الفوضى أيضًا (انظر py2 و py3 في السنوات القليلة الأولى)؟

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

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

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

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

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

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

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

أنا أتفق معك بالفعل ، لكني لا أرى كيف يكون ذلك ممكنًا بدون ضخ كبير في التمويل / الرؤية. يشكل NumPy مجموعة ضخمة من العمل. ربما يقوم teoliphant و skrah بإخراجها من خلال الملذات ، لكنها ستكون معركة شاقة.

بالنظر إلى NumPy الذي لدينا اليوم ، أعتقد أننا نقوم به كما يمكننا القيام به بشكل معقول.

بالنسبة لأولئك الذين أجابوا بـ "نعم" ، السؤال الثاني: هل يمكنك تسمية أي برنامج آخر غير numpy قام بهذا من قبل؟

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

أنا في الواقع أتفق معك ،

@ shoyer من الفائدة ، لماذا؟ كيف لا يتحول ذلك إلى انتقال مؤلم للغاية يشبه الانتقال إلى قاعدة الشفرة الجديدة في مرحلة ما؟

هذه هي سياسة اللغات المعيارية (C ، Fortran) وكذلك مكتبات البنية التحتية (BLAS ، LAPACK ، MPI ، ...). ومع ذلك ، يحدث الابتكار (مثل ATLAS).

الابتكار في وتيرة LAPACK / ATLAS / OpenBLAS هو وصفة لنمباي تحول الكثير غير ذي صلة بشكل أسرع مما كان خلاف ذلك من شأنه.

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

كيف لا يتحول ذلك إلى انتقال مؤلم للغاية يشبه الانتقال إلى قاعدة الشفرة الجديدة في مرحلة ما؟

الاختلاف الكبير هو أنه في حين أن Python 3 عبارة عن مفتاح كل شيء / لا شيء (لبرامج Python) ، فمن السهل أو على الأقل يمكن القيام به لمزج / مطابقة مكتبات ndarray المختلفة. تعني واجهة المخزن أنه يمكنك نقل البيانات ذهابًا وإيابًا بدون نسخ. إذا قمت بإجبار المدخلات على وظائفك باستخدام np.asarray() فقد لا تلاحظ حتى ما إذا كانت بعض المكتبات تعمل مع مفاتيح لإرجاع مصفوفات من نوع مختلف.

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

إذا فرض الجميع مدخلاتهم باستخدام np.asarray ، فلن يكون np.matrix مشكلة :-).

إذا تمكنت مكتبات المصفوفات المختلفة من الاتفاق على أنواع البط وقمنا بتقييد أنواع dtypes التي يمكن تمثيلها بواسطة بروتوكول المخزن المؤقت ، فيمكنها العمل. ولكن إذا كان الهدف الكامل من إعادة الكتابة هو إجراء تغييرات واجهة غير متوافقة على كائنات المصفوفة وتنفيذ أنواع جديدة ، ... لا أرى حقًا كيفية إنجاحها. مثال ملموس: أحد الأشياء الواضحة التي يجب إصلاحها في هذا النوع من إعادة الكتابة هو سلوك ndarray.dot على المدخلات عالية الأبعاد. ولكن إذا كانت هناك مكتبة تقوم بعمل def f(a, b): a.dot(b) ، فمن المحتمل أن يؤدي إنشاء مثل هذه المكتبة إلى كسرها. لا يهم حقًا ما إذا كانت تلك المكتبة تسمى numpy أم لا.

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

rgommers يرجى قراءة ما كتبته مرة أخرى: لا أقترح ،

njsmith أحد الجوانب الرئيسية لإعادة التصميم كما أراه هو التخلي عن OO. إنها ليست طريقة جيدة لهيكلة التعليمات البرمجية لهيكل بيانات واحد يحتوي على العديد من الوظائف التي تعمل عليه. اكتب np.dot(a, b) وستتبخر المشكلة التي تصفها على الفور. يمكنك الحصول على أي عدد من عمليات التنفيذ namespace.dot تريدها. يمكن لكل مكتبة استخدام المكتبة التي تفضلها ، ولا يزال بإمكانها التعامل مع بعضها البعض. إنها OO التي تنشئ مساحة اسم واحدة للطرق ، وهذه مشكلة.

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

فقط لإظهار أنني أستطيع أن أؤيد كسر الأشياء ؛-)

rgommers يرجى قراءة ما كتبته مرة أخرى: لا أقترح ، لا أكرر ، اقترح أن يعتمد NumPy وتيرة LAPACK.

انا افهم ذلك. فقرتي ردي لم تكن مرتبطة بشكل مباشر ، آسف إذا كان ذلك مربكًا.

أقترح أنه يشير بوضوح للأشخاص الذين لديهم مثل هذا التوقع (أي 80 ٪ من الناس في بيئتي) أنه لا يفعل ذلك.

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

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

njsmith نفس المشكلة ، بطريقة ما. الفهرسة هي استدعاء طريقة في Python ، لذا فهي OO مرة أخرى.

ملاحظة جانبية: الفهرسة الفاخرة هي أكبر خطأ تصميم في NumPy ، في رأيي ، لأنها لا تحتوي (ولم يكن لديها) مواصفات لا لبس فيها. تقوم بعمل np.take للوسيطات الصحيحة و np.repeat للوسيطات المنطقية. نظرًا لأن القيم المنطقية هي نوع فرعي من الأعداد الصحيحة في بايثون ، فإن هذا يخلق غموضًا بالنسبة للوسيطات التي تحتوي على 0 و 1 فقط.

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

أناقش الفهرسة الفاخرة في دورات SciPy حصريًا لأخبر الناس بعدم استخدامها. هناك np.take و np.repeat والتي تعمل بشكل جيد ولا تسبب أي مشكلة. وإذا كنت تستخدمها كوظائف بدلاً من طرق ، فلا توجد مشكلة OO أيضًا. بالنسبة لأولئك الذين لا يحبون np.repeat لأن الاسم لا يشير إلى النية عند استخدامه مع القيم المنطقية ، ما عليك سوى تقديم اسم مستعار: select = np.repeat . مرة أخرى شيء صعب بلا داع بواسطة OO.

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

المسألة الشائكة من وجهة نظري حسابية. أنت تريد كتابة a+b لإضافة المصفوفة ، بدلاً من np.add(a, b) ، لكن لا يوجد اتفاق عام حول ما يجب أن يفعله a+b بالضبط ، لا سيما من حيث نوع النتيجة dtype . كانت هذه إحدى القضايا الأساسية في الانقسام الرقمي / الرقمي ، والذي أدى إلى إدخال أنواع عددية جديدة في NumPy ، وتسبب ذلك أيضًا في نصيبها العادل من المفاجآت غير السارة. أعتقد أنه يمكن حل هذه المشكلة ، ولكن ليس في الملاحظات الجانبية حول مناقشة قضية GitHub.

rgommers إذا كان "طلب إصدار مثبت بنسبة 80٪" ممكنًا ، كنت سأفعل ذلك منذ فترة طويلة. "80٪" ليس مجتمعًا منظمًا يمكنك التحدث إليه. يتشارك عدد كبير من الأشخاص في خلفية ثقافة ، لكن لا يتفاعلون مع بعضهم البعض. اقتراحك يشبه إلى حد ما "مطالبة مستخدمي Windows بالتبديل إلى Linux" (أو العكس).

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

لا أريد أن أخرج هذا عن مساره أكثر من اللازم ، لكن ليس لدي أي فكرة عما تشير إليه بمصفوفات np.repeat و bool

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

نقطة جانبية ، لأن هذا لن يحدث على أي حال بعد الآن :). أنا في الواقع آمل إلى حد ما أن يؤدي إصلاح الأشياء ببطء في numpy إلى جعل الأمر أسهل في وقت ما في المستقبل لجعل numpy أكثر قابلية للاستبدال.

اقتراحك يشبه إلى حد ما "مطالبة مستخدمي Windows بالتبديل إلى Linux" (أو العكس).

حسنًا ، إن سؤال الأشخاص المؤهلين تقنيًا (آمل ...) لمعرفة كيفية عمل أرقام الإصدارات في العالم الحقيقي في الواقع ليس شيئًا مثل تبديل Windows إلى Linux.

هذه هي النقطة التي أحاول توضيحها من خلال الإصرار على أن NumPy هو برنامج للبنية التحتية.

ومن المفترض ، إذا أجرينا هذا التبديل ، فستنتقل إلى SciPy لأنه الجزء التالي من البنية التحتية؟ متى تتوقف عن كونها بنية تحتية؟ ولماذا تريد NumPy وأجزاء أخرى من البنية التحتية الحصول على مخطط إصدار مختلف تمامًا عن Python نفسها وبقية نظام Python البيئي العلمي بأكمله؟

إن 80٪ "ليس مجتمعًا منظمًا يمكنك التحدث إليه.

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

seberg إن التصريح بأن القوائم والمصفوفات هي أنواع بيانات مختلفة تشترك فقط في الفهرسة كخاصية مشتركة هو وجهة نظر صالحة لاعتمادها. كما أنه سيجعل من السهل شرح وجود مقاييس NumPy محددة. لكني لم أر أي عرض لـ NumPy يأخذ وجهة النظر هذه.

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

يجب على مديري أجهزة الكمبيوتر العملاقة التي تستخدمها التحدث مع بعضهم البعض ، أليس كذلك؟

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

لم أقصد أنه يجب عليك تعليم 80٪ من جميع مسؤولي النظام في جميع أنحاء العالم ، فقط أولئك الذين تحتاجهم.

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

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

لمعرفة كيفية عمل أرقام الإصدارات في العالم الحقيقي

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

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

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

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

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

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

ومن المفترض ، إذا أجرينا هذا التبديل ، فستنتقل إلى SciPy لأنه الجزء التالي من البنية التحتية؟ متى تتوقف عن كونها بنية تحتية؟

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

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

ولماذا تريد NumPy وأجزاء أخرى من البنية التحتية الحصول على مخطط إصدار مختلف تمامًا عن Python نفسها وبقية نظام Python البيئي العلمي بأكمله؟

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

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

وبنية البيانات المركزية مستقرة. الغالبية العظمى من التغييرات غير المتوافقة في أي إصدار معين هي حالات زاوية ومعظمها ليست في سلوك ndarray. راجع https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes على سبيل المثال. لاحظ أيضًا أن أيًا من هذه التغييرات لن يكون له أي معنى بالنسبة لمسؤول النظام ، لذلك حتى لو حدق في تلك الملاحظات لفترة طويلة (إذا كان ذلك سيكون 2.0.0) فلن يتمكن من تحديد ما إذا كانت الترقية على ما يرام أم ليس.

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

يستخدم SciPy نفس نظام الإصدار وسياسة الإيقاف / الإزالة تمامًا مثل NumPy. كونك في 0.x لفترة طويلة لا يعني semver.

الذي هو (كما أراه) السائد في الحوسبة العلمية

المقارنات التقليدية لنظام SciPy البيئي مع أشياء مثل Matlab و R. لا يمكن العثور على أي معلومات حول R ، لكنها في 3.x وقد تطورت كثيرًا ، لذلك ربما لا يكون semver. مطلاب: بالتأكيد ليس سمفر.

RE: فهرسة خيالية. في الواقع ، يمكن أن يستخدم هذا وظيفة مخصصة. هذا ما تم إجراؤه في TensorFlow ، على سبيل المثال ، مع tf.gather ، tf.gather_nd ، tf.scatter_nd ، tf.boolean_mask ، إلخ. كانت النتيجة مطولة أكثر بقليل من زيادة التحميل على [] ، لكن بالتأكيد أكثر شفافية.

ميزة أخرى يمكن أن تساعد في كتابة التعليقات التوضيحية ، وهي ميزة كانت مدفوعة جزئيًا بصعوبة انتقال Python 2 إلى 3.

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

khinsen لقد كنت

حاليًا ، بفضل إطار عمل Apple Accelerate ، كان الحد الأدنى المطلوب لإصدار LAPACK هو 3.1.ish منذ أكثر من عقد من الزمان. وحاليا LAPACK هو 3.8.0. في غضون ذلك ، قاموا بإهمال عدد كبير من الإجراءات (تم إهمالها و / أو إزالتها) وإصلاح الكثير من الأخطاء والأهم من ذلك تقديم إجراءات جديدة مطلوبة لسد الفجوة بين البرامج التجارية وبرامج Python العلمية. يتم تلخيص النتيجة النهائية هنا . لقد كنت دائمًا مزعجًا بشكل رئيسي rgommers وآخرين على مدار الأشهر الستة الماضية من أجل هذا 😃 ويمكنني أن أؤكد لك إذا كانوا من النوع الذي صورته هنا ، ربما عن غير قصد ، كان من المفترض أن يحدث هذا الآن وكسر رمز الكثيرين اشخاص. بدلاً من ذلك ، كانوا يشرحون بصبر لماذا ليس من السهل إسقاط الدعم لـ Accelerate.

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

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

حاليًا ، بفضل إطار عمل Apple Accelerate ، يكون الحد الأدنى المطلوب لإصدار LAPACK هو 3.1.ish

mhvk ، قد تكون هذه مشكلة لـ # 9976 في 1،14 ، والتي أعتقد أنها تحتاج إلى 3.2.2 (تحرير: دعنا ننتقل للمناقشة هناك)

xoviat : دعونا نجري هذه المناقشة حول هذه المسألة

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

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

في عالم Fortran / C ، لا توجد مثل هذه المشكلة لأن حزم البرامج ضحلة. هناك Fortran و LAPACK وكود التطبيق ، بدون وسيطة إضافية. ما يحدث هو أن كل رمز تطبيق يختار إصدارًا معينًا من LAPACK وفقًا لأولوياته. تحتفظ مراكز الحوسبة عادةً بالعديد من إصدارات LAPACK بالتوازي ، كل منها في دليلها الخاص ، ويتم الاختيار عن طريق تعديل رمز التطبيق Makefile .

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

لذا فإن اقتراحي لمعضلة SciPy / LAPACK هو الحفاظ على SciPy اليوم باستخدام Accelerate ، ولكن وضعه في وضع الصيانة الأدنى (ربما تم الاستيلاء عليه بواسطة أشخاص مختلفين) يمكن للأشخاص الذين يريدون Accelerate اختيار "SciPy 2017" ليكونوا سعداء. لن يحصلوا على ميزات LAPACK الجديدة ، ولكن من المفترض أن هذا جيد في معظمهم. يستمر التطوير في مساحة اسم جديدة ( scipy2 ، scipy2018 أو أي شيء آخر) ، والتي تتحول إلى LAPACK الحديثة. إذا كان ذلك ممكنًا من الناحية الفنية ، اسمح بالتثبيت المتوازي لهذين المتغيرين (والمستقبليين) (والذي أعتقد أنه سيكون ممكنًا لـ SciPy). خلاف ذلك ، سيتعين على الأشخاص الذين يحتاجون إلى كليهما استخدام بيئات متعددة (كوندا ، أو venv ، أو بيئات على مستوى النظام عبر Nix أو Guix). لاحظ أنه حتى في هذا السيناريو الثاني ، أوصي بشدة بتغيير مساحة الاسم مع كل تغيير غير متوافق ، للتأكد من أن قراء كود Python في أي مستوى يفهمون أي إصدار SciPy تمت كتابة الكود.

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

تشير الفكرة العامة القائلة بأن التطوير والتجميع يتم بشكل مستقل ومن قبل أشخاص مختلفين أيضًا إلى أنه يجب تقسيم الحزم الضخمة اليوم إلى وحدات أصغر يمكنها التقدم بمعدلات مختلفة. لا يوجد سبب اليوم لاحتواء NumPy على واجهة LAPACK صغيرة وأدوات مثل f2py . بالنسبة لـ SciPy ، قد يكون من المنطقي أن يكون لديك مساحة اسم مشتركة تشير إلى التماسك وسياسة تطوير مشتركة ، ولكن يمكن توزيع الحزم الفرعية بشكل مستقل. يعود نهج الحزمة الضخمة إلى شعار بايثون "البطاريات المضمنة" والذي كان رائعًا قبل 20 عامًا. تعد قاعدة المستخدمين اليوم متنوعة للغاية لذلك ، وقد تم التعرف على حزم البرامج بشكل عام على أنها نشاط متميز. يجب أن يكون تضمين البطاريات الآن وظيفة Anaconda.

العقبة الرئيسية أمام تبني مثل هذا النهج هي توزيعات Linux التقليدية مثل Debian أو Fedora بنهجها "تثبيت Python واحد لكل جهاز". أعتقد أنه بإمكانهم التبديل إلى بيئات افتراضية متعددة على مستوى النظام بجهد معقول ، لكنني لم أفكر كثيرًا في هذا الأمر. بالنسبة لي ، فإن مستقبل حزم البرامج هو أنظمة قائمة على البيئة مثل conda أو Guix.

لا أرى كيف تتوافق جميع أحرف الجر التي ذكرتها حتى الآن مع أي من هذه الخطوات

  • لقد قمت للتو بإعادة إنشاء جنون الصورة التالية
    image
    عدت للتو ولدي 27 نسخة الآن على جهاز Windows الخاص بي. الآن اضرب ذلك في 10 منذ (الإصدارات هنا في كثير من الأحيان) و 2 (نظرًا لأن دورات إطلاق NumPy و SciPy مستقلة). في عام 2025 ، سأحصل بسهولة على 15 نسخة من كل مكتبة و 10 LAPACKs و 5 f2pys كاعتماديات. ناهيك عن عبء الصيانة على مجموعة من عشرات الأشخاص في كلتا الحزمتين ، فهذا ببساطة لن ينجح. (C ++ ليست ذات صلة ، أدخل أي شفة قياسية لأي شيء). اسأل أي مطور كود تجاري عن Win وأخبره أن هذه فكرة جيدة. لست مسؤولاً عما يلي في هذا التبادل.
  • ثم قمت بزيادة دقة الحزم وكلها تقوم الآن بالأشياء بمفردها باستخدام إصدارات مختلفة من الحزم ؛ كسر f2py شيئًا ما في إصدار واحد ، لذا توقف SciPy عن البناء في الإصدار التالي ولكن لا يزال يعتمد على الإصدار السابق من NumPy. لذلك يجب على بعض الكيانات الشاملة أن تجمعهم معًا مجانًا.
  • ثم أيضًا جعلت Anaconda (أو كيانًا آخر) شركة ذات اعتماد كبير تمامًا مثل Accelerate. أو ببساطة سيكون هناك وفرة من "شخص آخر".
  • ثم حشدت معظم قاعدة المستخدمين في سير عمل لا يريدونه حقًا (بمن فيهم أنا) يتضمن بيئة افتراضية.
  • ثم قمت حتى بتعديل أنظمة تشغيل Linux بشكل عابر (وهو ... أعني فقط قراءة بعض القوائم البريدية الخاصة بهم ، إنه ممتع).

ربما استطعت قليلا.

(لقد أصبح هذا نقاشًا مجانيًا للجميع ، لذلك سأستمر وأقفز).

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

xoviat تمت مناقشة هذه كلها في https://github.com/scipy/scipy/pull/6051. كالمعتاد أبدا بهذه البساطة. لكن النقطة ليست مناقشة الإسقاط السريع ولكن استخدامه كحالة استخدام لدورة التطوير الفعلية للإصدارات الجديدة.

ilayn نعم ، أنا متأكد من أنني أعرف بالفعل النقاط التي

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

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

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

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

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

راجع للشغل ، أنا في الواقع أتابع القائمة البريدية لتوزيع Linux واحد (Guix). ليس الكثير من المرح ، ولكن الكثير من العمل الشاق. أنا سعيد بوجود أشخاص يفعلون هذا.

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

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

إذا كانت الصورة المثالية صحيحة ، فلن نرى شوكات ، ولن يكون لدينا بيئات افتراضية. ولا مشاريع مثل VersionClimber .

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

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

xoviat لا ، لست

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

لكنني متأكد من أن هناك الكثير من مستخدمي SciPy الذين لا يحتاجون إلى الوظائف المتأثرة على الإطلاق.

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

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

في الواقع ، أعتقد أن أناكوندا SciPy تم تجميعها باستخدام MKL ، لذلك لن تتأثر في هذه الحالة. ولكن بعد ذلك لماذا تهتم بتسريع الدعم؟

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

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

xoviat من السهل لأي شخص الاحتفاظ بفرع منفصل. ليست هناك حاجة لاستضافته في نفس مستودع GitHub. بمعنى آخر ، الفروع ليست هي المشكلة. تكمن المشكلة في مسافة الأسماء ، من أجل جعل الوجود المتوازي لإصدارات SciPy المنفصلة شفافًا للمستخدمين (ومجمعات التوزيع).

اليوم ، عندما ترى رمزًا يقول "استيراد scipy" ، فليس لديك فكرة عن مجموعة إصدارات SciPy التي من المفترض أن تعمل (أي تم اختبارها إلى حد ما). في أفضل الأحوال ، هناك عبارة README تقول "SciPy> = 0.8" أو شيء من هذا القبيل. تستند هذه العادة على افتراض أن الإصدارات "الأعلى" دائمًا ما تكون "أفضل" ولا تتحلل أبدًا (تنكسر ، تبطئ ، ...) أي شيء. وهذا الافتراض خاطئ تمامًا.

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

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

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

أفترض أن إنشاء هذا النوع من الحزم الإضافية ممكن. أتوقع أيضًا أنه سيخلق نوعًا مختلفًا من الجحيم. قد يبقى الكثير على قيد الحياة ، لكن التحقق من الكتابة على سبيل المثال لن ولن يتمكن من ذلك عند مزج نسختين ، لذلك لن تعرف في الأساس ما إذا كان يمكن أو لا يمكن أن يعمل حتى تحاول (ولن يختبر أحد ذلك!).
وما لم تكن تقترح السماح بخلط نسختين ، أعتقد أن حل scipy2017 سيجعل الأمور أسوأ. يبدو أننا سنحتاج إلى شيء مثل اختيار البيئة الافتراضية الديناميكية / وقت التشغيل (مثل pin_import_version("1.6<numpy<1.10", level="raise") قبل أي استيراد على مستوى Python).

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

تم تقديم التوافق المتخلف NEP # 11596 ، هل يمكننا إغلاق هذا؟

تم تقديم التوافق المتخلف NEP # 11596 ، هل يمكننا إغلاق هذا؟

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

شكرا للجميع على المناقشة.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات