[Python-projects] Using pyLint with Django (or other 3rd party libraries)

[Emile Anclin]

hello, 

It seems to be an open issue; however, I don't know much Django. 
Could you tell us more about your problem ?
How is "objects" implemented in models.Model ?

thanks for your remarks

On Fri, Sep 05, 2008 at 10:07:42AM -0700, Rogan Creswick wrote:
> First off, I am a "seasoned" developer, but I am new to python,
> pylint, and django.
> 
> I would very much like to integrate pylint into the build process for
> my python projects, but I have run into one show-stopper:  One of the
> error types that I find extremely useful--:E1101: *%s %r has no %r
> member*--constantly reports errors when using common django fields,
> for example:
> 
> E1101:125:get_user_tags: Class 'Tag' has no 'objects' member
> 
> which is caused by this code:
> 
> def get_user_tags(username):
>    """
>    Gets all the tags that username has used.
> 
>    Returns a query set.
>    """
>    return Tag.objects.filter(  ## This line triggers the error.
>        tagownership__users__username__exact=username).distinct()
> 
> # Here is the Tag class, models.Model is provided by Django:
> class Tag(models.Model):
>    """
>    Model for user-defined strings that help categorize Events on
>    on a per-user basis.
>    """
>    name = models.CharField(max_length=500, null=False, unique=True)
> 
>    def __unicode__(self):
>        return self.name
> 
> I believe this is caused because pyLint is unable to find, and/or
> incorporate information about the superclasses used by the model
> classes in my django projects. (Tag, in this case).  I've looked over
> the tutorial, user manual, and help output for pylint, and I haven't
> found any way to direct pylint at the django source so that it can
> identify the fields that are inherited from the superclass objects.
> (The portions of the user manual that look like they would cover this
> have not yet been written.)
> 
> Could someone please let me know what, if anything, I can do to get
> around this?  I do not consider disabling E1101 to be an option -- it
> checks for precisely the type of error I'm concerned about, and
> indeed, if I use an object like a model class when it is *not* a model
> class, that should be caught!
> 
> Thank you,
> Rogan Creswick
> _______________________________________________
> Python-Projects mailing list
> Python-Projects at lists.logilab.org
> http://lists.logilab.org/mailman/listinfo/python-projects
>