title: Using Pylint with Django
body: <p>I would very much like to integrate <a href="http://www.logilab.org/857" rel="noreferrer">pylint</a> 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--:<code>E1101: *%s %r has no %r
  member*</code>--constantly reports errors when using common django fields,
  for example:</p>
  
  <pre><code>E1101:125:get_user_tags: Class 'Tag' has no 'objects' member
  </code></pre>
  
  <p>which is caused by this code:</p>
  
  <pre><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
  </code></pre>
  
  <p>How can I tune Pylint to properly take fields such as objects into account?  (I've also looked into the Django source, and I have been unable to find the implementation of <code>objects</code>, so I suspect it is not "just" a class field.  On the other hand, I'm fairly new to python, so I may very well have overlooked something.)</p>
  
  <p><strong>Edit:</strong> The only way I've found to tell pylint to not warn about these warnings is by blocking all errors of the type (E1101) which is not an acceptable solution, since that is (in my opinion) an extremely useful error.  If there is another way, without augmenting the pylint source, please point me to specifics :)</p>
  
  <p>See <a href="http://creswick.github.io/blog/2008/09/05/wrestling-python/" rel="noreferrer">here</a> for a summary of the problems I've had with <code>pychecker</code> and <code>pyflakes</code> -- they've proven to be far to unstable for general use.  (In pychecker's case, the crashes originated in the pychecker code -- not source it was loading/invoking.)</p>