-
-
Notifications
You must be signed in to change notification settings - Fork 293
very long run time and/or stack overflow during inference #7
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: