Open kcdodd opened 2 weeks ago
As a small update, I was wondering why the non-daemon mypy command did not crash even though it should be going through the same analysis. Apparently mypy.main sets the recursion limit to 2**14 (or 16384) but mypy.dmypy leaves the default limit (1000 in this case).
I have linked a pull request that makes these consistent, which might address this by itself. But it also includes a proposed method of handling such expressions, even though its probably up for debate what the proper handling of it should be.
Crash Report
I have been unable to use dmypy for a while due to recursion error, but finally took the time to figure out why. This seems to happen when processing a dependency, SymPy source file+line: https://github.com/sympy/sympy/blob/e676df8ded885babe62bd31bec5db8c96b7480e7/sympy/polys/numberfields/resolvent_lookup.py#L248. It seems that the AST of the expression is just simply too deep to process before hitting recursion limit, estimating its a couple thousand nodes deep.
Honestly, I wouldn't consider this a bug, except that it crashes the daemon and prevents it from processing anything else. The ast module clearly warns "It is possible to crash the Python interpreter with a sufficiently large/complex string due to stack depth limitations in Python’s AST compiler.", so it might even be close to that limit as well.
But if there was a way of simply not processing such large nodes, or recovering, I think that would deserve a "fix".
Traceback
To Reproduce
Run dymy on https://github.com/sympy/sympy/blob/e676df8ded885babe62bd31bec5db8c96b7480e7/sympy/polys/numberfields/resolvent_lookup.py.
Your Environment
dmypy run -- sympy/polys/numberfields/resolvent_lookup.py