Numpy: خطأ: test_big_arrays (test_io.TestSavezLoad) في OS X + Python 3.3

يمكنني إعادة إنتاج هذا. يبدو وكأنه خطأ في Python 3.x.

import os
import sys
import time


if sys.maxsize > 2**32:
    print('64-bit')
else:
    print('32-bit, exiting')
    sys.exit(0)

fname = 'write_large_bytestring.txt'
tmp = open(fname, 'wb')
try:
    L = (1 << 31) + 100000
    tmp.write(b'abc' * 2**32)
finally:
    tmp.close()
    os.remove(fname)
    print('Elapsed time: %s s' % time.clock())

ما سبق يعمل مع Python 2.7 ولكن ليس مع 3.3:

$ python tmp3.py 
64-bit
Elapsed time: 7.896957 s

$ python3.3 tmp3.py 
64-bit
Elapsed time: 50.149956 s
Traceback (most recent call last):
  File "tmp3.py", line 16, in <module>
    tmp.write(b'abc' * 2**32)
OSError: [Errno 22] Invalid argument

$ ulimit
unlimited

يتم تثبيت كلا بايثون من dmgs على python.org. لا يمكنني العثور على مشكلة لهذا على bugs.python.org ولكن IIRC تمت إعادة كتابة الوحدة النمطية io بالكامل.

تم تقديم الاختبار في gh-2942.

أو ربما هذا خطأ آخر OSX I / O؟ تذكر أن OSX libc هي عربات التي تجرها الدواب ولديها مشاكل في fwrite / fread عند التعامل مع كتل بيانات قريبة من 2 ** 32 ، والتي كان علينا حلها في الملف الشخصي / من الملف ...

على أي حال ، من الواضح أنه يتعين علينا حلها عن طريق تقسيم الكتابة
إلى قطع أصغر ، أليس كذلك؟

(حتى لو كان خطأ libc في النهاية ، فمن المحتمل أن يعمل Python على حل المشكلة
هو نفسه - ربما كان لدى 2.7 رمز للقيام بذلك والذي فقد في ملف
انتقال.)
في 3 أكتوبر 2013 10:03 ، كتب "Pauli Virtanen" [email protected] :

أو ربما هذا خطأ آخر OSX I / O؟ تذكر ، OSX libc عربات التي تجرها الدواب ولديها
مشاكل في الكتابة / القراءة عند التعامل مع كتل بيانات قريبة من 2 ** 32 ...

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/numpy/numpy/issues/3858#issuecomment -25607852
.

إعادة: gh-574 و gh-2806 و gh-3473 قد تكون نسخة OSX المعنية ذات صلة ، ربما تفشل الآن بدلاً من كتابة القمامة كما فعلت سابقًا؟

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

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

هل هذا مانع 1.8.0؟ سأضعه هناك فقط حتى لا يُنسى ، ويمكن دائمًا إزالته. لا أحد يعرف ما إذا كان يعمل مع Python 3.2؟

أيضًا ، IIRC ، لقد قمنا بتقسيم القراءات فقط ، فقد يكون الاختبار الذي يكتب ملفًا كبيرًا معطلاً.

لن أوقف إصدار هذا ، إنه ليس تراجعًا. ضع علامة عليها معروفة بالفشل في الفرع 1.8.x إذا لم تفشل قبل الإصدار.

rgommers هل إذا فشلت فقط مع OSX و 3.3؟ أنت تقول أنه يعمل مع Python 2.7 ، هل هذا صحيح؟

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

rgommers لذا OSX بشكل عام. سأتركه مفتوحًا في 1.9-devel لتحفيز الإصلاح وفتح مشكلة.

تم الإبلاغ عن هذا ثابتًا في OS X Mavericks. ربما لن يتم إصلاح هذا ، لأن الإصلاح المناسب هو ترقية نظام التشغيل.

أنظر أيضا # 2931.

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

لا يزال هذا يحدث بالنسبة لي على مافريكس مع numpy 1.8.1 و python 3.4 (أيضًا 3.3) من Anaconda ؛ إذا قمت بالتعليق على المصمم skipif ، يفشل https://github.com/numpy/numpy/blob/v1.8.1/numpy/lib/tests/test_io.py#L154 .

نجح الاختبار ، ويبدو أن البيانات قد تم تحميلها بشكل صحيح ، باستخدام python 2.7 من Anaconda.

هذا ليس بالضرورة عيبًا في numpy ، ولكن يبدو أن الآخرين يعملون على حل هذه المشكلة أو ما شابهها ، على سبيل المثال https://github.com/torch/torch7-distro/commit/40e65934e071e452f194a9d8c0fd740131babefa (وهو للقراءة بدلاً من الكتابة ، ولكن أنا أيضًا غير قادر على قراءة الملفات الكبيرة على Python 3).

يؤدي تشغيل حقيبة الاختبار باستخدام Python 3.4 مع numpy 1.8.1 على نظام التشغيل Mac OS X 10.9.4 (Mavericks) إلى ظهور الخطأ OSError: [Errno 22] Invalid argument المعروف. certik يرجى إعادة فتح القضية!

نقطة بيانات أخرى - باستخدام OSX 10.9.5 (Mavericks) وأواجه نفس المشكلة. لقد رأيت للتو هذا الخطأ في متتبع بيثون: https://bugs.python.org/issue24658

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

يحدث هنا ، أحدث إصدار من macOS و python (3.6) و numpy.

لمعلوماتك لا تزال ترى هذا الخطأ على أحدث إصدار من macOS (10.12.6) و Python 3.5.2 (Anaconda 4.2.0).
هل اكتشف أي شخص حدًا أعلى لأحجام القطع؟

الحصول على هذا الخطأ أيضًا ، macOS Sierra ، python 3.6 ، numpy

يبدو أن هناك بعض الحركة بشأن قضية بايثون ، ولكن ربما ينبغي علينا المضي قدمًا وتقسيم الكتابات.

يبدو أن هذا لن يتم إصلاحه في المنبع في أي وقت قريبًا. أي شخص يعرف آخر حالة؟

تحية للجميع،

هل يمكنك تجربة هذه المشكلة مع الإصدار الأخير من Python 3.6 و 3.7 و 3.8a لأنني أعتقد أنه تم إصلاح المشكلة على OSX مع هذا PR (https://github.com/python/cpython/pull/1705).

لديّ علاقات عامة أخرى مقابل 2.7 ، لكن هذا ليس جاهزًا بعد: /

شكرا لك على ملاحظاتك.

rgommers أي فرصة يمكنك اختبار هذا؟ نرحب بأي ملاحظات أخرى حول الوضع الحالي لهذا الأمر.

اجتاز الاختبار test_big_arrays ، لكن https://github.com/numpy/numpy/issues/3858#issuecomment -25607105 لا يزال يفشل بالنسبة لي مع أحدث إصدار من Python 3.6 تم شحنه بواسطة Anaconda. ربما لا يحتوي هذا على إصلاح CPython بالرغم من ذلك. لا وقت لبناء بايثون بنفسي الآن ، آسف.

rgommers هل يمكنك إعادة زيارة هذا؟

تم إصلاح هذا بالفعل بقدر ما أستطيع أن أقول ، على الأقل مع Python 3.7 من Anaconda. لا توجد تقارير أخرى سواء ، إغلاق لذلك. شكرًا للجميع ، و @ matrixise على وجه الخصوص لإصلاح هذا الأمر.