-
-
Notifications
You must be signed in to change notification settings - Fork 281
very long run time and/or stack overflow during inference #7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
1 similar comment
Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?): there is much probably an infinite loop somewhere which doesn't end into an |
Original comment by Buck Evan (BitBucket: bukzor, GitHub: @bukzor?): My hypothesis is different: I believe it's tracing all the possible assignment paths in a permutative manner, yielding O(n^n) performance. With smaller numbers (3-10), it does complete, just exponentially slower for each new method. |
Original comment by BitBucket: eevee, GitHub: @eevee?: I looked into this a bit in the course of trying to improve pylint performance on a large and terrible codebase. :) Buck is correct; this is equivalent to
This repeats rather ridiculously. Every assignment of I think I have a small fix for this, which involves extending the existing recursive-inference protection to avoid inferring the same attribute on an instance of the same class twice in the call stack. I'll post it as soon as I figure out how to do that with hg and bitbucket. :) |
Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?): sounds good eevee, thanks ! don't hesitate to ask for help for submitting your patch. |
Original comment by Buck Evan (BitBucket: bukzor, GitHub: @bukzor?): @eevee Put your diff on http://paste.pound-python.org/ if you're really stuck on bitbucket/hg. This page always gives me enough information to do what I need with hg: http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table |
Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?): @eevee any update on this? Astroid should be released soon, it would be great if it could include a fix for this one. |
Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?): Avoid recursively inferring the same attr on the same class. Closes #7 |
Originally reported by: Buck Evan (BitBucket: bukzor, GitHub: @bukzor?)
This simple script generates a (admittedly perverse) class which, when analyzed causes astroid to stack overflow.
http://paste.pound-python.org/show/HvGNK3BPWVkbqY1VAlyl/
If the number of methods is somewhat reduced, a huge running time is incurred instead, which is (for me) even worse. I'm trying to measure it, but currently it's ten minutes and counting.
Here is a trace of the inference being performed at the time of stack overflow:
http://paste.pound-python.org/show/QEm5Q15I1WMrHGnrWyqU/
This is a real issue for us as the cheetah templating framework generates code equivalent to the above. This causes pylint to be unusable to check these generated files. I do want to check these generated python files for issues, and pylint seems like the most full-featured tool available.
The text was updated successfully, but these errors were encountered: