QuerySet is inferred as list

[matsui-goga]

If you define the objects attribute of a model as models.Manager(), you get error

E:  5, 3: Instance of 'list' has no 'exists' member (no-member)

on

q = AModel.objects.filter(...)
if q.exists():
   ...

I'm using pylint 1.9.1, pylint-django 0.11.1.

[mahmoud]

Is this not a Manager getting inferred as a list? In any case, yes, I'm seeing this a lot:

Instance of 'list' has no 'prefetch_related' member
Instance of 'list' has no 'exclude' member
Instance of 'list' has no 'filter' member
Instance of 'list' has no 'aggregate' member

And myriad others. Will try and take a look, see how this can be fixed. Also, on the same versions as above.

[atodorov]

q = AModel.objects.filter(...)
if q.exists():

The problem comes from the second line. In this example q is inferred as list and then you get failures.

pylint-django uses transformations which try to teach it what type an object/attribute is and what other attributes there are.

For this to be resolved effectively we need to teach pylint-django about all Manager methods that return a QuerySet.

@carlio ^^^ not sure what I'm getting myself into with this proposition. Ideas ?

[carlio]

@atodorov well pylint-django is already a huge shim and things like this exist: https://github.com/PyCQA/pylint-django/blob/master/pylint_django/augmentations/__init__.py#L37 and also https://github.com/PyCQA/pylint-django/blob/master/pylint_django/transforms/fields.py#L31

The whole thing is about second-guessing Django metaprogramming to fit into pylint's expectation of what things are.

So what you're getting yourself into is: adding more special cases to lots of special cases because that's really all that can be done!

[carlio]

Though another thought - originally the problem was that any import of django.models resulted in django trying to configure itself, which is why there are many workarounds. This was from 4 years ago though so that might be out-of-date. Perhaps a 'try: django.configure() except: <load some default config in the pylint-django lib' could work now? If the environment is not set up to load whatever config users have, then just fall back on some simple basics just to get django.conf.settings to be available and that'd solve lots of the problems of having to shim things together I would guess. Just an idea, I haven't tried this at all.

[mahmoud]

Just a heads up that I'm co-working with @ngtvspc on #175 as a fix for this, and invite anyone with expertise/advice to comment there.

[ajl7]

The problem seems to be caused by a transform in pylint-django that substitutes a Manager by something that returns a list for all the methods that return QuerySets: all(), filter(), etc. This doesn't allow for the same methods on the QuerySet itself, so it doesn't recognise chaining, e.g. MyModel.objects.filter(...).select_related(...).order_by(...)
If you replace transforms/transforms/django_db_models.py by the attached version, the errors disappear. I don’t know enough about pylint and pylint-django to know if this is an optimal or correct solution, but it seems to work for me. Maybe a test case for chaining such as the example above should be added?
Note that as well as the attached django_db_models.py, I also added ‘QuerySet’ to the _add_transform(‘django.db.models’,’Model’,’Manager’) call in transforms/__init__py
I hope this is helpful.
django_db_models.py.txt

[atodorov]

Can you retry with pylint-django 2.0 that was released today ?

[matsui-goga]

It works. Thank you.
I wish we could use it with Python 2.7 too.

[carlio]

@matsui-goga the problem is that the latest pylint and django don't support 2.7 either so there's no point in pylint-django supporting it. Old versions of all those three still do though.