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.

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

Wrong not-an-iterable error when model objects is InheritanceManager #160

Closed
nirsalon opened this issue Apr 24, 2018 · 2 comments
Closed

Comments

@nirsalon
Copy link

Repro steps:

from model_utils.managers import InheritanceManager

class Unit(models.Model):
    sim = models.CharField(max_length=64, null=True, blank=True)
    objects = InheritanceManager()

installed_units = Unit.objects.filter(sim__isnull=False)
ids = [u.sim for u in installed_units]

Run pylint and get:
[E1133(not-an-iterable), ] Non-iterable value installed_units is used in an iterating context

using pylint==1.8.4 and pylint-django==0.11

@dianedelallee
Copy link

+1
using pylint==1.9.1 and pylint-django==0.11

@atodorov
Copy link
Contributor

Note for maintainers:

ids = [u.sim for u in installed_units]

the error message is generated by the line above. In this context installed_units is a Name node with the inferred type of None from what I can tell.

I've toyed around making this work but couldn't. What I did was use node.frame() to start from the function/class or module that defined the variable. Search through all Assign nodes and their AssignName targets to match node.name. By doing this we're trying to identify the last time this variable has been re-assigned some value so we can later infer the type of this value and try to disable the error message based on that.

I managed to reach a Call to the .filter() attribute of the manager and failed to proceed further.

On a side note I was examining only .frame().body which is only the 1st level of nodes defined in the outer scope. We can have variables being redefined inside loops and if conditions so maybe inspect all children in the AST tree ?!?

I will give this another try tomorrow using the transforms machinery and basically redefine InheritanceManager and friends as iterators. If it works fine, if it doesn't then I'm open to suggestions.

atodorov added a commit that referenced this issue May 25, 2018
instead of trying to special-case this like we did before I've
added transformation definitions which allow pylint to properly
infer the types of the overriden object managers and know that
they are iterators.
atodorov added a commit that referenced this issue May 25, 2018
instead of trying to special-case this like we did before I've
added transformation definitions which allow pylint to properly
infer the types of the overriden object managers and know that
they are iterators.
atodorov added a commit that referenced this issue May 25, 2018
instead of trying to special-case this like we did before I've
added transformation definitions which allow pylint to properly
infer the types of the overriden object managers and know that
they are iterators.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants