Numpy: إنشاء "متحكم فيه" لصفائف الكائن

سيكون أحد الخيارات
"" الثعبان
محاولة:
# استبق اللعبة وقم بترقية الإهمال إلى خطأ سيحل محله
مع تحذيرات.catch_warnings ():
warnings.filter warnings ('push'، DeprecationWarning، message = "...")
c_arr = np.asarray (ج)
باستثناء (DeprecationWarning ، ValueError):
# كل ما تفعله حاليًا من أجل ValueError

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

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

أعتقد أن زبد الشفرة يستحق فترة الإهمال.

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

لكن AFAICT لا يوجد حتى حل سهل بشكل معقول (كما هو موضح أعلاه الإصلاح المقترح ليس موضوعًا آمنًا) لذلك: /

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

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

فيما يتعلق بالتحذير من سلامة الخيط: https://bugs.python.org/issue37604

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

IMHO (بالاتفاق مع النقطة mattip أعلاه) هو نوع التغييرات التي سيكون من الأسهل بكثير التعامل معها في حالة حدوث التبديل إلى الرفع دون فترة إهمال. لست متأكدًا من أن هذا خيار على الرغم من: /

أو ربما تكون الفروع متعددة الأبنية مختلفة عن الرئيسية.

FWIW كنت دائمًا على الأقل -1 في هذا التغيير ، خاصةً كمستخدم قوي لهياكل البيانات الخشنة ، ولكن على أي حال الآن أنا بحاجة إلى معرفة ما يجب فعله حيال مئات حالات فشل الاختبار لـ SciPy 1.4.0rc2 الإعدادية في https://github.com/scipy/scipy/pull/11161

الآن أنا بحاجة لمعرفة ما يجب فعله حيال مئات الإخفاقات في الاختبار

سيكون الخيار السهل:

• قم بقمع التحذير في التكوين pytest الخاص بك
• افتح مشكلة لإصلاحها لاحقًا

بيت القصيد في استخدامنا DeprecationWarning بدلاً من ValueError هو إعطاء المشاريع النهائية والمستخدمين فترة سماح للقيام بذلك بالضبط.

AFAIK ، الإهمال في فرع التحرير. هل نريد التراجع عنه؟

أعتقد أننا نفعل ذلك ، إنها تمطر. لدينا الآن قائمة بالأشياء التي تم كسرها في Pandas و Matplotlib و SciPy وداخل numpy.testing و NumPy ufuncs ، == ، إلخ. أعتقد أننا يجب أن نعود التغيير الآن ونذهب لتقييم / إصلاح كل هؤلاء الأشياء ، ثم إعادة تقديم الإهمال.

هل يمكننا التنازل عن تحذير معلق؟

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

يبدو أننا ابتعدنا عن الإصدار الأصلي ، والذي يبدو أنه "نظرًا لتسلسل القيم ، كيف يمكن لـ matplotlib تحديد ما إذا كانت لونًا واحدًا أم قائمة ألوان". أعتقد أنه يجب أن يكون هناك حل لا يتطلب نقل القيم إلى ndarray ، والتحقق من نوع dtype لتلك المصفوفة. قد يكون نوعًا من الدالة العودية is_a_color() حلاً أفضل.

لقد عدت عن التغيير لـ 1.18.x في # 15053.

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

إذا لم تكن هناك طريقة حقًا ، فنحن بحاجة إلى قمع تحذير آمن للخيط. np.seterr المحتمل أن يحتوي

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

أعتقد أن المشكلة التي تطرحهاanntzer أكثر عمومية. يتعلق الأمر بكتابة دالة تأخذ أنواعًا عديدة من المدخلات ، بمنطق مثل:

• إنشاء ndarray(flexible_input)
• إذا كان `new_ndarray.dtype.kind == 'O': تعامل مع هذا
• آخر: use_the_array

بما أنه لا يمكن إضافة dtype=object إلى هذا الرمز ، فماذا يجب فعله؟

كما أن عمليات الإصلاح التي يقوم بها الباندا مقلقة بعض الشيء بالنسبة لي ، لأنها تستخدم catch_warnings .

لم يكن seberg أفضل من suppress_warnings لهذا؟

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

لست متأكدًا تمامًا مما إذا كانت الحالات الإشكالية تعمل ضد الهدف الأصلي (https://numpy.org/neps/nep-0034.html) لم نتوقعها.

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

~~~
np.array (data، dtype = 'allow_object')

np.array (البيانات ، allow_object_dtype = صحيح)

باستخدام np.array_create_allow_object_dtype ():
np.array (بيانات)
~~~

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

أليست حالة matplotlib في الواقع:

with np.forbid_ragged_arrays_immediately():
    np.array(data)

بما أنك تريد حقًا اكتشاف الخطأ ، بدلاً من الحصول على نوع كائن؟

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

FWIW أعتقد أن معظم الأماكن في mpl التي وصلت إلى هذا يمكن إصلاحها (مع إعادة هيكلة أكثر أو أقل - في حالة واحدة يتحول الكود إذا كان أسرع بعد ...).
أعتقد أن واجهة برمجة التطبيقات المقترحة من timhoffm ستكون أجمل من with np.forbid_ragged_arrays_immediately: لأنه يمكن بسهولة كتابة الأخيرة من حيث الأولى (زيادة إذا np.array(..., allow_object=True).dtype == object ) بينما العكس ( try: with np.forbid: ... except ValueError: ... ) سيكون أقل كفاءة إذا كنا لا نزال نريد إنشاء مصفوفة كائنات بعد كل شيء. لكن CM (مجرد "التحرك محليًا بعد فترة الإهمال") سيكون أفضل من لا شيء.

(مرة أخرى ، أعتقد أن التغيير جيد ، يتعلق الأمر فقط بكيفية تنفيذه).

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

1. الخلط بين object و "allow ragged" . إذا كانت الكائنات من نوع معقول (على سبيل المثال Decimal ) فأنت تريد بالفعل الحصول على تحذير / خطأ ولكن قد تحتاج أيضًا إلى تمرير dtype=object
2. لا توجد طريقة للاشتراك في السلوك الجديد أو الاستمرار في استخدام القديم (دون سابق إنذار). يبدو على الأقل أن Opt-In ضروري للاستخدام الداخلي ، إذا لم نوفره ، فإننا نفترض أساسًا (ربما بشكل غير مباشر) أن المستخدمين النهائيين هم فقط من يواجهون هذه الحالات؟

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

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

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

حجة لعدم التراجع بعد - في حين أن التغيير في حالة رئيسية ، يمكننا الاستفادة من عمليات تشغيل CI في اتجاه المصب لمحاولة إيجاد الحلول التي ستبدو عليها

CI المصب أحمر ، وهذا _ جدا_ غير مفيد. لدينا الآن قائمة الإخفاقات الخاصة بهم ، ولسنا بحاجة إلى الاحتفاظ بـ CI باللون الأحمر لجعل حياتنا أسهل قليلاً هنا.

وعلى الأقل فإن CI الخاص بـ Matplotlib يعمل مقابل pip install --pre وليس الفرع الرئيسي

وعلى الأقل فإن CI الخاص بـ Matplotlib يعمل مقابل pip install --pre وليس الفرع الرئيسي

هذا ينسحب من العجلات الليلية كما يبدو. تم إرجاع التغيير بالفعل لـ 1.18.0rc1 ، لذلك يجب ألا تراه إذا كنت ستثبّت بـ --pre من PyPI.

ترقى بعض التعليقات المذكورة أعلاه إلى إعادة التفكير في التغييرات المقترحة في NEP 34. لست متأكدًا مما إذا كان هذا الموضوع هو المكان المناسب لمواصلة هذه المناقشة ، ولكن هنا يذهب. (لا ضرر إذا كان يجب مناقشته في مكان آخر - من السهل نسخ التعليقات ولصقها.: ابتسم: أيضًا ، رأى بعضكم تباينًا في هذه التعليقات في مناقشة حول Slack.)

بعد التفكير في هذا الأمر مؤخرًا ، انتهى بي الأمر بنفس فكرة اقتراحtimhoffm الأول (وربما تم اقتراح الفكرة في أوقات أخرى في الأشهر القليلة الماضية): تحديد سلسلة محددة أو كائن مفرد ، عند إعطائه كـ الوسيطة dtype لـ array ، تسمح للوظيفة بالتعامل مع المدخلات الخشنة عن طريق إنشاء مصفوفة كائن 1-d. في الواقع ، يتيح هذا السلوك السابق لـ NEP-34 لـ dtype=None حيث يتم تحويل المدخلات الخشنة الشكل تلقائيًا إلى مصفوفة كائن. في حالة تقديم أي قيمة أخرى لـ dtype (بما في ذلك None أو object ) ، يتم إعطاء تحذير بالإيقاف إذا كان الإدخال خشن الشكل. في إصدار مستقبلي من NumPy ، سيتم تحويل هذا التحذير إلى خطأ.

أعتقد أنه من الواضح الآن أن استخدام dtype=object لتمكين معالجة المدخلات الخشنة الشكل ليس حلاً جيدًا للمشكلة. من الناحية المثالية ، يمكننا فصل مفاهيم "مجموعة الكائنات" عن "المصفوفة الخشنة". لكن لا يمكننا فصلهم تمامًا ، لأننا عندما نريد التعامل مع مصفوفة خشنة ، فإن الخيار الوحيد أمامنا هو إنشاء مصفوفة كائنات. من ناحية أخرى ، نريد أحيانًا مصفوفة كائنات ، لكننا لا نريد التحويل التلقائي لمدخلات خشنة الشكل إلى مصفوفة كائن من التسلسلات.

على سبيل المثال (راجع العنصر 1 في آخر تعليق لـ seberg ) ، افترض أن f1 و f2 و f3 و f4 هي Fraction كائنات Fraction s. لست مهتمًا بإنشاء مجموعة خشنة. إذا كتبت عن غير قصد a = np.array([f1, f2, [f3, f4]], dtype=object) ، فأنا أرغب في إنشاء خطأ ، لجميع الأسباب التي تجعلنا نمتلك NEP 34. ومع ذلك ، مع NEP 34 ، سيؤدي ذلك إلى إنشاء مصفوفة 1-d بطول 3.

تبدو البدائل التي تضيف وسيطة كلمة رئيسية جديدة ، مثل الاقتراح الثاني لـ timhoffm ، أكثر تعقيدًا من اللازم. المشكلة التي نحاول حلها هي "مسدس القدم" حيث يتم تحويل المدخلات الخشنة تلقائيًا إلى مصفوفة كائنات أحادية الأبعاد. تظهر المشكلة فقط عندما يتم تمرير dtype=None إلى array . إن مطالبة المستخدمين باستبدال dtype=None بـ dtype=<special-value-that-enables-ragged-handling> للحفاظ على السلوك القديم المزعج هو تغيير بسيط لواجهة برمجة التطبيقات التي يسهل شرحها. هل نحن حقا بحاجة إلى أكثر من ذلك؟

أعتقد أنه من الواضح الآن أن استخدام dtype=object لتمكين معالجة المدخلات الخشنة الشكل ليس حلاً جيدًا للمشكلة. من الناحية المثالية ، يمكننا فصل مفاهيم "مجموعة الكائنات" عن "المصفوفة الخشنة".

تبدو معقولة ، ربما. من الجيد أيضًا الإشارة إلى أنه لا يوجد مفهوم "مصفوفة خشنة" حقيقي في NumPy . إنه شيء لا ندعمه بشكل أساسي (ابحث عن كلمة "خشنة" في المستندات ، أو في أداة تعقب المشكلات أو القائمة البريدية لتأكيد ما إذا كنت تريد ذلك) ، وهو شيء يدعمه DyND و XND ، وقد بدأنا الحديث عنه فقط للحصول على موجز عبارة لمناقشة "نريد إزالة السلوك np.array([1, [2, 3]]) الذي يؤدي إلى تعثر المستخدمين". ومن ثم فإن الخبز في "المصفوفات الخشنة" كشيء جديد لواجهة برمجة التطبيقات يجب أن يتم بحذر شديد ، فهو ليس شيئًا على الإطلاق نريد الترويج له. لذا سيكون من الجيد توضيح ذلك في تسمية أي dtype=some_workaround قد نضيفه.

يبدو أن الرأي العام يتحد حول حل لتمديد الإهمال (ربما إلى أجل غير مسمى) من خلال السماح np.array(vals, dtype=special) والذي سيتصرف كما كان قبل NEP 34. أفضل استخدام مفرد بدلاً من سلسلة ، لأنه يعني أن استخدامات المكتبة يمكن أن تفعل special = getattr(np.special, None) وستعمل الكود الخاص بهم عبر الإصدارات.

الآن نحن بحاجة إلى تحديد الاسم وأين يجب الكشف عنه. ربما never_fail أو guess_dimensions ؟ أما بالنسبة لمكان الكشف عنها ، فأنا أفضل عدم تعليقها على np بدلاً من بعض الوحدات الداخلية الأخرى ، ربما مع _ للإشارة إلى أنها واجهة خاصة حقًا.

أعتقد أن الطريق إلى الأمام هو تعديل NEP 34 ، ثم فضح المناقشة على القائمة البريدية.

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

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

هل يمكن لشخص ما أن يشير إلى المثال operator.mod ؟

بالنسبة إلى عامل التشغيل == ، الذي رأيته كان يفعل شيئًا مثل np.array(vals, dtype=object) == vals حيث vals=[1, [2, 3]] (إعادة صياغة الرمز) ، لذا فإن الحل هو إنشاء المصفوفة بشكل استباقي على اليمين الجانب.

يبدو أن العديد من حالات الفشل scipy على شكل np.array([0.25, np.array([0.3])]) ، حيث خلط الحجميات و ndarray مع shape==(1,) سوف يتعارض مع اكتشاف البعد وإنشاء مصفوفة كائن. اكسريف gh-15075

هل يمكن لشخص ما أن يشير إلى المثال operator.mod ؟

رأيت ذلك في Pandas PR الخاص بـ jbrockmendel ، لكنني أعتقد أنه قد تغير منذ ذلك الحين (لا ترى صريحًا operator.mod في التعليقات بعد الآن).

بالنسبة إلى عامل التشغيل == ، الذي رأيته كان يفعل شيئًا مثل np.array(vals, dtype=object) == vals حيث vals=[1, [2, 3]] (إعادة صياغة الكود) ، لذا فإن الحل هو إنشاء المصفوفة بشكل استباقي على اليمين الجانب.

عند هذه النقطة يصبح الأمر np.array(vals, dtype=object) == np.array(vals, dtype=object) ، لذا من الأفضل حذف الاختبار :)

mattip كتب:

أنا أفضل استخدام مفرد بدلاً من سلسلة نصية ، لأنه يعني أن استخدامات المكتبة يمكن أن تقوم بعمل خاص = getattr (np.special ، لا شيء) وستعمل التعليمات البرمجية الخاصة بهم عبر الإصدارات.

هذا يبدو جيدا بالنسبة لي.

الآن نحن بحاجة إلى تحديد الاسم وأين يجب الكشف عنه. ربما never_fail أو guess_dimensions ؟ بالنسبة لمكان الكشف عنها ، أفضل عدم تعليقها على np بدلاً من بعض الوحدات الداخلية الأخرى ، ربما مع _ للإشارة إلى أنها واجهة خاصة حقًا.

اسم عملي الحالي لهذا هو legacy_auto_dtype ، ولكن هناك على الأرجح العديد من الأسماء الأخرى التي لن أشكو منها.

لست متأكدًا من أن الاسم يجب أن يكون خاصًا. بأي تعريف عملي لـ _private_ و _public_ ، سيكون هذا كائنًا _public_. يوفر للمستخدمين وسيلة للحفاظ على السلوك القديم ، على سبيل المثال ، array(data) عن طريق إعادة كتابته كـ array(data, dtype=legacy_auto_dtype) . أتخيل أن السياسة الاقتصادية الجديدة (NEP) المحدثة ستوضح أن هذه هي الطريقة التي ينبغي بها تعديل الكود للحفاظ على السلوك القديم (بالنسبة لأولئك الذين يجب عليهم القيام بذلك). إذا كان الأمر كذلك ، فإن الكائن بالتأكيد ليس خاصًا. في الواقع ، يبدو أنه كائن عام سيبقى في NumPy إلى أجل غير مسمى. لكن ربما يكون فهمي للكيفية التي ستتم بها خطة NEP 34 المعدلة خاطئًا.

تمت الموافقة على وصف

Re name: الرجاء اختيار اسم يصف الوظيفة. أشياء مثل "الإرث" لا تكاد تكون فكرة جيدة.

الرجاء اختيار اسم يصف الوظيفة.

auto_object ، auto_dtype ، auto ؟

التفكير بصوت عالٍ قليلاً ...

ماذا يفعل هذا الشيء؟

حاليًا ، عندما يتم إعطاء NumPy كائن Python يحتوي على تكرارات لاحقة لا تتوافق أطوالها مع المصفوفة العادية ، فإن NumPy ستنشئ مصفوفة بنوع بيانات object ، مع وجود الكائنات في المستوى الأول حيث يحدث عدم تناسق الشكل تُركت ككائنات بايثون. على سبيل المثال ، شكل array([[1, 2], [1, 2, 3]]) شكل (2,) ، np.array([[1, 2], [3, [99]]]) له شكل (2, 2) ، إلخ. مع NEP 34 ، نحن نتجاهل هذا السلوك ، لذا نحاول إنشاء مصفوفة تحتوي على مدخلات "خشنة" ستؤدي في النهاية إلى حدوث خطأ ، ما لم يتم تمكينها صراحةً. القيمة الخاصة التي نتحدث عنها تمكن السلوك القديم.

ما هو الاسم الجيد لذلك ؟ ragged_as_object ؟ inconsistent_shapes_as_object ؟

عند هذه النقطة يصبح الأمر np.array(vals, dtype=object) == np.array(vals, dtype=object) ، لذا من الأفضل حذف الاختبار :)

حسنًا ، كنت أعيد الصياغة. الاختبار الفعلي يشبه إلى حد كبير my_func(vals) == vals يجب أن يصبح my_func(vals) == np.array(vals, dtype=object)

سأقترح تمديدًا لـ NEP 34 للسماح بقيمة خاصة لـ dtype.

لاحظ أنه يبدو أن scipy لا يحتاج إلى هذا الحارس لاجتياز الاختبارات مع scipy / scipy # 11310 و scipy / scipy # 11308

تم دمج gh-15119 ، والذي أعاد تنفيذ السياسة الاقتصادية الجديدة. إذا لم يتم التراجع عنها ، فيمكننا إغلاق هذه المشكلة

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