¿Por qué hay un límite de longitud para la evaluación de python?

No estoy abogando por que esto sea una buena idea, pero descubrí que puedes bloquear Python (2.7 y 3.2 marcados) ejecutando eval en una cadena de entrada lo suficientemente grande:

 def kill_python(N): S = '+'.join((str(n) for n in xrange(N))) return eval(S) 

En mi computadora, S puede generarse muy bien, pero para valores de aproximadamente N>74900 , Python fallará con la Segmentation fault (core dumped) . ¿Hay un límite a la longitud de la cadena (o árbol de análisis) que el intérprete puede manejar?

Nota : No necesito hacer esto, para mí esta es una pregunta más profunda que refleja mi ignorancia de lo que sucede dentro de la caja. Me gustaría entender por qué Python falla aquí, y de manera tan catastrófica (¿por qué no lanzar una excepción?)

Este problema se debe a un desbordamiento de stack en el comstackdor CPython. Una forma fácil de reproducir el mismo problema es

 >>> code = compile("1" + "+1" * 1000000, "", "eval") Segmentation fault 

lo que prueba que la falla de seguridad está ocurriendo en la etapa de comstackción, no durante la evaluación. (Por supuesto, esto también es fácil de confirmar con gdb.)

[Nota al margen: para expresiones más pequeñas, el comstackdor aplicaría el plegado constante aquí de todos modos, por lo que lo único que sucede durante la ejecución del código es cargar el resultado:

 >>> code = compile("1" + "+1" * 1000, "", "eval") >>> eval(code) 1001 >>> dis.dis(code) 1 0 LOAD_CONST 1000 (1001) 3 RETURN_VALUE 

Fin de la nota al margen.]

Este problema es un defecto conocido . Los desarrolladores de Python recostackron varias formas de bloquear al intérprete de Python en el directorio Lib/test/crashers de la distribución de origen. El que corresponde a este problema es Lib/test/crashers/compiler_recursion.py .