Numpy: في بعض الأحيان ، تفقد supress_warnings إحدى سماتها

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

نظرًا لعدم وجود assert_warns أو هكذا أعتقد هنا. يجب أن يكون لديك سياق suppress_warnings واحد فقط على قيد الحياة (والذي سيكون النطاق الأبعد ويتم إنشاؤه بواسطة عداء اختبار numpy ، على افتراض أن الكشط ينتهي باستخدامه). الآن لماذا أشعر بالارتباك ، هو أن _orig_show لم يتم تعريفه يجب ألا يكون ممكنًا إلا إذا تم الخروج من السياق بالفعل. في ذلك الوقت ، يجب إعادة تعيين warnings.showwarning بالفعل إلى القيمة القديمة.

بالطبع تتعطل عناصر التحذيرات بأكملها إذا كان لديك خيوط. فمثلا:

thread1: يدخل سياق التحذير -> يستبدل الطباعة التحذيرية العادية
thread2: يدخل سياق التحذير -> يستبدل معالج التحذير thread1
thread1: يخرج من سياق التحذير -> يعيد التعيين إلى طباعة التحذير العادية
Thread2: يوجد سياق تحذيري -> يعيد تعيين معالج التحذير الخاص بـ thread1 -> kaboom.

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

لقد واجهت المشكلة للتو عندما حاولت إنشاء عرض سريع لدبيان ، وليس لدي أي فكرة هنا. ومع ذلك ، فتحت scikit-image / scikit-image # 2412 لإشراكهم.

فقط من أجل الاكتمال: في بعض الأحيان ، أحصل على تتبع مكدس دون أي تدخل في الكشط:

ERROR: test suite for <module 'skimage.transform.tests' from '/build/skimage-0.12.3/debian/tmp/usr/lib/python3/dist-packages/skimage/transform/tests/__init__.py'>
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 229, in run
    self.tearDown()
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 352, in tearDown
    self.teardownContext(ancestor)
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 368, in teardownContext
    try_run(context, names)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
    inspect.getargspec(func)
  File "/usr/lib/python3.5/inspect.py", line 1040, in getargspec
    stacklevel=2)
  File "/usr/lib/python3/dist-packages/numpy/testing/utils.py", line 2199, in _showwarning
    self._orig_show(message, category, filename, lineno,
AttributeError: 'suppress_warnings' object has no attribute '_orig_show'

ما هي إصدارات python و numpy وما إلى ذلك التي تجمعها؟

Numpy 1.12 ~ RC ~ beta 1 و Python 2.7 و 3.5
(عذرًا ، خطئي: لم أفحص RC بعد)

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

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

olebole كيف تقوم بالضبط بتشغيل بدلة الاختبار؟

منسوخة من مجموعة الاختبار الخاصة بنا:

#!/bin/sh
set -efu

pys="$(pyversions -rv 2>/dev/null)"
pkgbuild=${pkgbuild:-no}

srcdir=$PWD

for py in $pys; do
    echo "=== python$py ==="
    if [ "$pkgbuild" = "yes" ]; then
        export PYTHONPATH="$srcdir/debian/tmp/usr/lib/python$py/dist-packages"
        cd "$srcdir/build/"
    else
        cd "$ADTTMP"
    fi

    xvfb-run -a python$py /usr/bin/nosetests -s -v --exclude test_tools.py skimage 2>&1
done

xvfb-run موجود حيث يجب تشغيل الاختبار في بيئة X11.

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

في صفحة دليل nosetests الخاصة بي ، لدي

       --processes=NUM
              Spread  test run among this many processes. Set a number equal to the number of processors or cores in your machine for best results. Pass a negative
              number to have the number of processes automatically set to the number of cores. Passing 0 means to disable parallel testing.  Default  is  0  unless
              NOSE_PROCESSES is set. [NOSE_PROCESSES]

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

هل هناك أي فرصة بعيدة أن يقوم الأنف بتشغيل هذا teardownContext بناءً على أشياء جمع القمامة ؟!

لا ، ربما أكون سخيفة. يعيد سياق تحذير الإيقاف تعيين warnings.showwarning قبل أن يحذف السمة ، لذا أشك حتى أن gc ketting in لا يمكنه فعلاً إنشاء أي شيء دون حدوث شيء آخر. ليس لدي فكرة ماذا بعد :).

حسنًا ، أرى 33 خطأً مع skimage-0.9.3 ، معظمها من PIL أو الفهرسة ، لكن لا شيء للقمع. كيف تتعامل مع كل الأخطاء الأخرى؟

charris تم الإبلاغ عن المشكلة لـ 0.12.3 وليس 0.9.3. :)

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

python -c'import skimage; skimage.test()'

لأن nosetests لا يعمل على الإطلاق.

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

sciunto يمكن أن تستخدم المستندات تعليمات للاختبار محليًا.

حسنًا ، أراه في نفس المكان. الاختبار هو

def test_vectorized_integrate():
    r0 = np.array([12, 0, 0, 10, 0, 10, 30])
    c0 = np.array([10, 0, 10, 0, 0, 10, 31])
    r1 = np.array([23, 19, 19, 19, 0, 10, 49])
    c1 = np.array([19, 19, 19, 19, 0, 10, 49])

    expected = np.array([x[12:24, 10:20].sum(),
                         x[:20, :20].sum(),
                         x[:20, 10:20].sum(),
                         x[10:20, :20].sum(),
                         x[0,0],
                         x[10, 10],
                         x[30:, 31:].sum()])
    start_pts = [(r0[i], c0[i]) for i in range(len(r0))]
    end_pts = [(r1[i], c1[i]) for i in range(len(r0))]
    assert_equal(expected, integrate(s, r0, c0, r1, c1))  # test deprecated
    assert_equal(expected, integrate(s, start_pts, end_pts))

يوحي لي التعليق # test deprecated أنه ربما يحتاج الاختبار إلى بعض الإصلاح ، ولكن لا يزال يجب أن يفشل suppress_warnings أكثر رشاقة.

مزيد من المعلومات قليلا ، القيام به

$ python skimage/transform/tests/test_integral.py

الذي يستخدم NumPy run_module_suite لا يبدو أنه يفشل ، لكنه يصدر التحذير

======================================================================
ERROR: skimage.transform.tests.test_integral.test_vectorized_integrate
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/charris/Workspace/scikit-image/skimage/transform/tests/test_integral.py", line 46, in test_vectorized_integrate
    assert_equal(expected, integrate(s, r0, c0, r1, c1))  # test deprecated
  File "/home/charris/Workspace/scikit-image/skimage/transform/integral.py", line 86, in integrate
    warn("The syntax 'integrate(ii, r0, c0, r1, c1)' is "
  File "/home/charris/Workspace/scikit-image/skimage/_shared/_warnings.py", line 16, in warn
    warnings.warn(message, stacklevel=stacklevel)
UserWarning: The syntax 'integrate(ii, r0, c0, r1, c1)' is deprecated, and will be phased out in release 0.14. The new syntax is 'integrate(ii, (r0, c0), (r1, c1))'.

لاحظ أن scikit-image لها مدير سياق خاص بها للتحذيرات في skimage/_shared/_warnings.py . قد يتعارض ذلك مع suppress_warnings .

بدافع الفضول ، أتساءل عما إذا كان هناك فرق في تحديد DeprecationWarning بشكل صريح بدلاً من استخدام UserWarning الافتراضي.

لذلك لا أرى أخطاء في

$ nosetests-2.7 skimage/transform/tests/test_integral.py |& grep orig_show

بينما

$ nosetests-2.7 skimage/transform/tests/ |& grep orig_show

يظهر ذلك حوالي 25٪ من الوقت. يشير ذلك إلى أن مصدر الخطأ يكمن في مكان آخر وأن الاختبار الفاشل يكشفه.

على وجه الخصوص ، يحتوي skimage/transform/tests/test_geometric.py على مدير سياق التحذيرات expected_warnings وهذا يجعلني أشعر بالريبة.

حسنًا ، الآن أشك في مصمم الديكور test_parallel ، https://github.com/scikit-image/scikit-image/blob/master/skimage/_shared/testing.py . هذا الافتراضيات إلى اثنين من المواضيع.

إذا قمت بإزالة الملفات الثلاثة التي تستورد test_parallel ، فلم تعد هناك مشكلة.

تحرير: والآن لا يمكنني إعادة إنتاج المشكلة على الإطلاق. حسنًا ... ربما يعتمد أيضًا على ما يتم تشغيله على الجهاز.

حسنًا ، يمكن أن يكون test_parallel كما أعتقد ، على الرغم من النظر في الكود ، من الواضح أن أيا من الوظائف لا تستخدم سياق تحذير ، على الرغم من أنه ليس مستحيلًا على ما أعتقد.

شيء ما في test_hough_transform.py يبدو أنه البادئ. مع إزالة هذا الملف لا يوجد خطأ.

تحرير: ربما لأنه يسبق الوحدة النمطية test_integral.py ؟

يبدو أن المشكلة تكمن في هذا الاختبار في test_hough_transform.py

@test_parallel()
def test_hough_circle():
    # Prepare picture
    img = np.zeros((120, 100), dtype=int)
    radius = 20
    x_0, y_0 = (99, 50)
    y, x = circle_perimeter(y_0, x_0, radius)
    img[x, y] = 1

    out1 = tf.hough_circle(img, radius)
    out2 = tf.hough_circle(img, [radius])
    assert_equal(out1, out2)
    out = tf.hough_circle(img, np.array([radius], dtype=np.intp))
    assert_equal(out, out1)
    x, y = np.where(out[0] == out[0].max())
    assert_equal(x[0], x_0)
    assert_equal(y[0], y_0)

في أي من السطرين

    assert_equal(out1, out2)

# or

    assert_equal(out, out1)

سيمكن الخطأ.

وبالمثل ، فإن إزالة مصمم الديكور @parallel يصلح الخطأ. لذا فالنتيجة هي أن الخيوط مع assert_equal استدعاؤها مع المتجهات تؤدي إلى المشكلة.

من المنطقي ، أن وظيفة التأكيد المتساوية تستخدمها لتصفية تحذيرات ".*NAT ==" ، ربما يمكننا محاولة إزالتها من هذه الوظيفة نظرًا لأنه ليس من الواضح حقًا أن assert_equal يقوم بالتحذير من القمع (وبالتالي لا يفعل ذلك بشكل كامل دعم الخيوط).

لطيفة تعقب تشاك!

محاولة إزالته سيكون شيئًا جيدًا.

أتساءل عما إذا كانت هناك وظائف أخرى غير آمنة للخيط؟

لست متأكدًا ، أعتقد أننا نستخدم فقط عناصر التحذير في بدلة الاختبار. و np.errstate ربما يكون موضوعًا آمنًا؟

شكرًا جزيلاً على هذا التحقيق الجميل charris و seberg

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

أعتقد أنه سيكون كافيًا فقط إصلاح assert_equal ، سيحتاج إلى إصلاح في المستقبل لمقارنة NaT في أي حال. لاحظ أنه يمكن تحويل NaT إلى int64 وله قيمة min_int64.

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

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

ما زلنا بحاجة إلى وظيفة isnat أو ربما ندعم datetime/timedelta في isnan .

نعم ، توافق على وظيفة isnat . يوجد أيضًا نوعان من أنواع الأكور: timedelta64 و datetime64 . لاحظ أن قيمة NaT لا تظهر في أي مكان أيضًا ، فمن المحتمل أن نستخدم np.nat أيضًا. التعريف الفعلي هو ndarraytypes.h .

charris ، تشاك ، ما رأيك في ذلك ، بدلاً من إنشاء np.isnat أو بالأحرى السماح بالتاريخ والوقت في isnan ؟

حسنًا ، وضع كل شيء في isnan هو فكرة مثيرة للاهتمام ولكني أظن أنه قد يسبب مشكلة في هذا الوقت ، ربما لاحقًا؟ njsmithjuliantaylor أفكار؟

shoyer قد يكون لها رأي أيضًا.

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

لا أعتبر الفشل شديد الخطورة ولكن سيكون من الجيد إصلاحه. إصدار بيثون (خاص؟) من isnat سيكون مناسبًا لي لـ 1.12.

يجب أن يذكر docstring suppress_warnings أنه ليس مؤشر ترابط آمن.

نعم هو كذلك :)

شكرًا جزيلاً يا رفاق على القفز على هذه المشكلة أثناء العطلات وعلى التصحيح الشامل

هل هناك أي شيء يمكنني القيام به لتنفيذ / اختبار حل لهذا؟ ديبيان حريص على إصلاح هذا :)

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

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

olebole هل سيعطل الاختبار المتوازي في skimage يكون حلاً مؤقتًا مقبولاً؟

seberg ، نعم ، أعتقد أن الهدف قد يكون الحصول على إصلاح

sandrotosi حاولت نهج القفل في gh-8427. أنا لا أفكر سواء كان الفكر مجنونًا أم لا ، ولكن إذا أراد شخص ما تجربته ...

هل هناك طريقة ما يمكننا من خلالها ببساطة تعديل suppress_warnings للحصول على سلوك غير محدد ولكن لا يتعطل عند استخدامه بطريقة متعددة الخيوط؟

(لدي بعض الأفكار ، لكنني ما زلت أفكر في كيفية عملها بالضبط).

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

لقد قمت بتحميل 1.12.0rc2 (الذي يحتوي على https://github.com/numpy/numpy/pull/8427) إلى debian وأعدت إنشاء سكيمج 3 مرات (إصدار قديم قليلاً من حزمة دبيان ، بدون تعطيل مجموعة الاختبار تمامًا) وكل الأوقات التي بُنيت فيها بنجاح.

شكرًا جزيلاً يا رفاق على العمل على هذا خلال العطلات!

الآن ، أي خطط لإصدار 1.12.0 النهائي؟ :)

أخطط لتقديم الإصدار النهائي في 15 يناير.

أستطيع أن أؤكد أنه يعمل مع rc2. شكرا جزيلا لجهودكم لك!

سأترك هذا مفتوحًا حتى يتم إصلاحه في الماجستير.

حسنًا ، ليس ثابتًا في الماجستير. seberg هل صحيح أن # 8421 سيغلق هذا؟

تم الإصلاح بواسطة # 8421.