Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Infinite loop calculating mro in astroid>=1.3.3 #37

Closed
carlio opened this issue Jan 24, 2015 · 4 comments
Closed

Infinite loop calculating mro in astroid>=1.3.3 #37

carlio opened this issue Jan 24, 2015 · 4 comments

Comments

@carlio
Copy link
Member

carlio commented Jan 24, 2015

As of astroid 1.3.3, class method resolution order is taken into consideration: https://bitbucket.org/logilab/astroid/commits/b1d8107715a4ceeeeb3f4a9065b67817e8cdc643

This caused an infinite loop when using pylint-django, as the model and form field transforms extended the base Django object then replaced it. This caused the MRO lookup to find a class as its own ancestor.
carlio added a commit that referenced this issue Jan 24, 2015
@carlio
[refs #37] As of astroid 1.3.3, class method resolution order is take…
653660d 
…n into consideration: https://bitbucket.org/logilab/astroid/commits/b1d8107715a4ceeeeb3f4a9065b67817e8cdc643

This caused an infinite loop when using pylint-django, as the model and form field transforms extended the base Django object then replaced it. This caused the MRO lookup to find a class as its own ancestor.

The model and form field transforms have been simplified, so that instead of building a module and replacing each class individually, instead, the correct "dummy" parent class is simply appended. This means that the original parent node (eg, CharField) is not replaced by itself. This also has the side effect of no longer confusing pylint when it comes to __init__/__new__ differences for field classes which extend "immutable" base classes as a result of this transform.
@carlio carlio mentioned this issue Jan 24, 2015
Closed
carlio added a commit that referenced this issue Jan 24, 2015
@carlio
[refs #37 #40] Fix the infinite loop problem using an inference tip t…
768aff5 
…o infer that fields are both their original subclass and also a type shim representing them at runtime. Also, supresses R0903 (too few methods) from models and views, which started happening recently
@akshayjshah
Copy link

Any chance of cutting a new release with this fix?

@carlio
Copy link
Member Author

carlio commented Jan 28, 2015

@akshayjshah I've been working on it but so far all my solutions have had the same problem. Getting closer though!

@akshayjshah
Copy link

Gotcha - thanks!

carlio added a commit that referenced this issue Jan 29, 2015
@carlio
Further purging of "inherit from self" failures [refs #37]
668532d
@carlio
Copy link
Member Author

carlio commented Jan 29, 2015

In the end I submitted a PR to astroid itself too: https://bitbucket.org/logilab/astroid/pull-request/67/mro-lookups-can-get-into-an-infinite-loop

However I don't know when that will be released so I've also patched pylint-django. Once I've verified it builds and the tests pass, and fixed a couple of small remaining bugs, I'll create a new PyPI release.

@carlio carlio closed this as completed Feb 10, 2015
This was referenced Dec 7, 2015
Closed
Closed
Closed
This was referenced Jul 16, 2017
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@carlio @akshayjshah