Numpy: ERROR: test_big_arrays (test_io.TestSavezLoad) en OS X + Python 3.3

Puedo reproducir esto. Parece un error de 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())

Lo anterior funciona con Python 2.7 pero no con 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

Ambos Python se instalan desde dmgs en python.org. No puedo encontrar un problema para esto en bugs.python.org pero IIRC el módulo io fue reescrito por completo.

Prueba introducida en gh-2942.

¿O quizás este es otro error de E / S de OSX? Recuerde, OSX libc tiene errores y tiene problemas en fwrite / fread cuando se trata de bloques de datos cercanos a 2 ** 32, que tuvimos que solucionar en tofile / fromfile ...

En cualquier caso, obviamente tenemos que solucionarlo dividiendo la escritura
en trozos más pequeños, ¿verdad?

(Incluso si en última instancia es culpa de libc, Python probablemente debería solucionar
él mismo - posiblemente 2.7 tenía un código para hacer esto que se perdió en el
transición.)
El 3 de octubre de 2013 a las 10:03, "Pauli Virtanen" [email protected] escribió:

¿O quizás este es otro error de E / S de OSX? Recuerde, OSX libc tiene errores y tiene
problemas en fwrite / fread cuando se trata de bloques de datos cercanos a 2 ** 32 ...

-
Responda a este correo electrónico directamente o véalo en Gi
.

Re: gh-574 y gh-2806 y gh-3473 La versión de OSX en cuestión puede ser relevante, tal vez ahora falla en lugar de escribir basura como lo hacía anteriormente

Sí, podemos solucionarlo fragmentando. Quizás este problema también debería enviarse a los desarrolladores de Python, para que también puedan implementar la fragmentación ellos mismos ...

Ah, me olvidé de esos temas. Intenté probar en mi máquina 10.6, pero el mismo script simplemente se cuelga. Sin embargo, podría deberse al hardware, es una máquina antigua.

¿Es este un bloqueador 1.8.0? Voy a ponerlo allí para que no se olvide, siempre se puede quitar. ¿Alguien sabe si funciona para Python 3.2?

Además, IIRC, solo hemos fragmentado las lecturas, puede ser que una prueba que escribe un archivo grande esté rota.

No retrasaría el lanzamiento de este, no es una regresión. Sin embargo, márquelo como conocido como error en la rama 1.8.x si no ha fallado antes del lanzamiento.

@rgommers ¿Si falla solo con OSX y 3.3? Dices que funciona para Python 2.7, ¿es correcto?

No falla para 2.7, pero la prueba no verifica que lo que se escribe en el archivo sea correcto. Es probable que no sea correcto, vea otros problemas que Pauli vinculó.

@rgommers So OSX en general. Lo dejaré abierto en 1.9-devel para motivar una solución y abrir un problema.

Esto se informó solucionado en OS X Mavericks. Es probable que esto no se solucione, ya que la solución adecuada es actualizar el sistema operativo.

Vea también # 2931.

Cierre, debe ser arreglado por Mavericks. Vuelva a abrir si el problema persiste.

Esto todavía me está sucediendo en Mavericks con numpy 1.8.1 y python 3.4 (también 3.3) de Anaconda; si comento el decorador skipif , https://github.com/numpy/numpy/blob/v1.8.1/numpy/lib/tests/test_io.py#L154 falla.

La prueba pasa y los datos parecen cargarse correctamente, usando Python 2.7 de Anaconda.

Esto no es necesariamente un defecto de numpy, pero otros parecen estar resolviendo este o problemas similares, por ejemplo, https://github.com/torch/torch7-distro/commit/40e65934e071e452f194a9d8c0fd740131babefa (que es para leer en lugar de escribir, pero Tampoco puedo leer archivos grandes en python 3).

Ejecutar el caso de prueba usando Python 3.4 con numpy 1.8.1 en Mac OS X 10.9.4 (Mavericks) da como resultado el conocido error OSError: [Errno 22] Invalid argument . @certik ¡Vuelve a abrir el problema!

Otro punto de datos: uso OSX 10.9.5 (Mavericks) y tengo el mismo problema. Acabo de ver este error en el rastreador de Python: https://bugs.python.org/issue24658

Bien podría reabrir esto. No sé si se solucionará cuando Python resuelva su parte, pero lo averiguaremos.

Sucede aquí, las últimas macOS, python (3.6) y numpy.

Para su información, sigo viendo este error en los últimos macOS (10.12.6) y Python 3.5.2 (Anaconda 4.2.0).
¿Alguien ha descubierto un límite superior en el tamaño de los fragmentos?

Recibiendo este error también, macOS Sierra, python 3.6, numpy

Parece haber algo de movimiento en el tema de Python, pero quizás deberíamos seguir adelante y dividir las escrituras.

Parece que esto no se solucionará pronto. ¿Alguien sabe el estado más reciente?

Hola a todos,

¿Podría intentar este problema con la última versión de Python 3.6, 3.7 y 3.8a porque creo haber solucionado el problema en OSX con este PR (https://github.com/python/cpython/pull/1705)?

Tengo otro PR para 2.7, pero este aún no está listo: /

Gracias por tus comentarios.

@rgommers ¿ Alguna posibilidad de que puedas probar esto? Cualquier otro comentario sobre el estado actual de esto sería bienvenido.

La prueba test_big_arrays pasa, pero https://github.com/numpy/numpy/issues/3858#issuecomment -25607105 aún me falla con el último Python 3.6 enviado por Anaconda. Sin embargo, probablemente no tenga la solución CPython. No hay tiempo para construir Python yo mismo ahora, lo siento.

@rgommers, ¿puedes volver a visitar esto?

De hecho, esto está arreglado por lo que puedo decir, al menos con Python 3.7 de Anaconda. Tampoco hay otros informes, así que cerrando. Gracias a todos, y a @matrixise en particular por arreglar esto.