Numpy: FEHLER: test_big_arrays (test_io.TestSavezLoad) unter OS X + Python 3.3

Ich kann das reproduzieren. Sieht aus wie ein Python 3.x-Fehler.

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())

Das Obige funktioniert mit Python 2.7, aber nicht mit 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

Beide Python werden von den dmgs auf python.org installiert. Ich kann auf bugs.python.org kein Problem dafür finden, aber IIRC, das Modul io wurde komplett neu geschrieben.

Test in gh-2942 eingeführt.

Oder ist dies ein weiterer OSX-E / A-Fehler? Denken Sie daran, OSX libc ist fehlerhaft und hat Probleme mit fwrite / fread beim Umgang mit Datenblöcken nahe 2 ** 32, die wir in tofile / fromfile umgehen mussten ...

In jedem Fall müssen wir das natürlich umgehen, indem wir den Schreibzugriff aufteilen
in kleinere Stücke, richtig?

(Auch wenn es letztendlich die Schuld von libc ist, sollte Python wahrscheinlich umgehen
es selbst - möglicherweise hatte 2.7 Code, um dies zu tun, der in der verloren ging
Überleitung.)
Am 3. Oktober 2013 um 10:03 Uhr schrieb "Pauli Virtanen" [email protected] :

Oder ist dies ein weiterer OSX-E / A-Fehler? Denken Sie daran, OSX libc ist fehlerhaft und hat
Probleme in fwrite / fread beim Umgang mit Datenblöcken nahe 2 ** 32 ...

- -
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie sich auf Gi tHubhttps an: //github.com/numpy/numpy/issues/3858#issuecomment -25607852
.

Betreff: gh-574 und gh-2806 und gh-3473 Die betreffende OSX-Version ist möglicherweise relevant. Vielleicht schlägt sie jetzt fehl, anstatt wie zuvor Müll zu schreiben?

Ja, wir können das umgehen, indem wir es aufteilen. Vielleicht sollte dieses Problem auch an Python-Entwickler weitergeleitet werden, damit diese auch selbst Chunking implementieren können ...

Ah, ich habe diese Probleme vergessen. Versucht, auf meinem 10.6-Computer zu testen, aber dort hängt nur das gleiche Skript. Könnte aber an der Hardware liegen, es ist eine alte Maschine.

Ist das ein 1.8.0 Blocker? Ich werde es dort ablegen, damit es nicht vergessen wird. Es kann immer entfernt werden. Weiß jemand, ob es für Python 3.2 funktioniert?

Außerdem, IIRC, haben wir nur Lesevorgänge aufgeteilt. Es kann sein, dass ein Test, der eine große Datei schreibt, fehlerhaft ist.

Ich würde die Veröffentlichung für diese nicht aufhalten, es ist keine Regression. Markieren Sie es im 1.8.x-Zweig als fehlgeschlagen, wenn es vor der Veröffentlichung nicht fehlgeschlagen ist.

@rgommers Scheitert es nur mit OSX und 3.3? Sie sagen, dass es für Python 2.7 funktioniert, ist das richtig?

Es schlägt für 2.7 nicht fehl, aber der Test überprüft nicht, ob das, was in die Datei geschrieben wurde, korrekt ist. Es ist wahrscheinlich nicht richtig, siehe andere Probleme, die Pauli verlinkt hat.

@rgommers Also OSX im Allgemeinen. Ich werde es in 1.9-Entwicklung offen lassen, um eine Lösung zu motivieren und ein Problem zu eröffnen.

Dies wird in OS X Mavericks behoben gemeldet. Dies wird wahrscheinlich nicht behoben, da die richtige Lösung darin besteht, das Betriebssystem zu aktualisieren.

Siehe auch # 2931.

Das Schließen sollte von Mavericks behoben werden. Bitte öffnen Sie erneut, wenn das Problem weiterhin besteht.

Dies geschieht immer noch für mich auf Mavericks mit Numpy 1.8.1 und Python 3.4 (ebenfalls 3.3) von Anaconda; Wenn ich den Dekorator skipif auskommentiere, schlägt https://github.com/numpy/numpy/blob/v1.8.1/numpy/lib/tests/test_io.py#L154 fehl.

Der Test besteht und die Daten scheinen korrekt geladen zu sein, wenn Python 2.7 von Anaconda verwendet wird.

Dies ist nicht unbedingt ein Fehler bei numpy, aber andere scheinen dieses oder ähnliche Probleme zu umgehen, z. B. https://github.com/torch/torch7-distro/commit/40e65934e071e452f194a9d8c0fd740131babefa (das eher zum Lesen als zum Schreiben dient, aber Ich kann auch keine großen Dateien auf Python 3) lesen.

Das Ausführen des Testfalls mit Python 3.4 mit numpy 1.8.1 unter Mac OS X 10.9.4 (Mavericks) führt zu dem bekannten Fehler OSError: [Errno 22] Invalid argument . @certik Bitte öffnen Sie die Ausgabe erneut!

Ein weiterer Datenpunkt - mit OSX 10.9.5 (Mavericks) bekomme ich das gleiche Problem. Ich habe diesen Fehler gerade im Python-Tracker gesehen: https://bugs.python.org/issue24658

Könnte dies auch wieder öffnen. Ich weiß nicht, ob es behoben wird, wenn Python ihren Teil löst, aber wir werden es herausfinden.

Passiert hier, neueste MacOS, Python (3.6) und Numpy.

Zu Ihrer Information: Dieser Fehler tritt immer noch unter dem neuesten MacOS (10.12.6) und Python 3.5.2 (Anaconda 4.2.0) auf.
Hat jemand eine Obergrenze für Blockgrößen herausgefunden?

Diesen Fehler auch bekommen, macOS Sierra, Python 3.6, numpy

Es scheint eine Bewegung in der Python-Frage zu geben, aber vielleicht sollten wir einfach weitermachen und die Schreibvorgänge aufteilen.

Sieht so aus, als würde dies nicht so schnell behoben werden. Kennt jemand den neuesten Status?

Hallo zusammen,

Könnten Sie dieses Problem mit der letzten Version von Python 3.6, 3.7 und 3.8a versuchen, da ich denke, dass das Problem unter OSX mit dieser PR behoben wurde (https://github.com/python/cpython/pull/1705).

Ich habe eine andere PR für 2.7, aber diese ist noch nicht fertig: /

Vielen Dank für dein Feedback.

@rgommers Gibt es eine Chance, dies zu testen? Jede weitere Rückmeldung zum aktuellen Stand wäre willkommen.

Der test_big_arrays -Test besteht, aber https://github.com/numpy/numpy/issues/3858#issuecomment -25607105 schlägt für mich mit dem neuesten Python 3.6 von Anaconda immer noch fehl. Das CPython-Update ist wahrscheinlich nicht vorhanden. Keine Zeit, Python selbst zu erstellen, sorry.

@rgommers kannst du das

Dies ist in der Tat behoben, soweit ich das beurteilen kann, zumindest mit Python 3.7 von Anaconda. Auch keine anderen Berichte, also abschließend. Vielen Dank an alle und insbesondere an @matrixise , die dies