[Python-projects] Supress checknig of imported module?

[Dalton, Tom]

Thanks to everynoe for the swift replies! I appreciate the reasons behind the pylint limitations, and I don't think they're a major problem (at least not for me). The ignored-classes option sounds like what I need, I'll check it out, thanks.

Unfortunately, the stub module idea would mean that I'd have to update the stub every time I updated the IDL, which itself is basically a stub of an interface hosted by the remote machine. So I think that would end up as too much work to maintain.

Just being able to ignore a class/module for the purpose of attr access is a godsend for me, as the number of errors from that one module were potentially masking a lot of other (real) errors.

Cheers,

Tom


-----Original Message-----
From: Sylvain Thénault [mailto:sylvain.thenault at logilab.fr]
Sent: Thu 20/11/2008 15:54
To: skip at pobox.com
Cc: Duncan Gibson; Dalton, Tom; python-projects at logilab.org
Subject: Re: [Python-projects] Supress checknig of imported module?
 
On Thu, Nov 20, 2008 at 09:40:33AM -0600, skip at pobox.com wrote:
> 
>     >> I don't want to globally supress E1101 and I dont want to supress the
>     >> error on ever line where I use omniDerivedThing. Is there a way to
>     >> tell pylint to ignore a particular imported module? 
>     ...
>     Duncan> I had a similar problem with an EnumerationType abstract base
>     Duncan> class written or adapted by a colleague, where each subclass was
>     Duncan> defined:
>     ...
> 
> There is only much pylint can do to divine module attributes.  Python is a
> bit too dynamic to allow pylint to work flawlessly in this area.  Mailman
> (and I think the email package) has a similar problem because it uses a lazy
> import mechanism.  When pylint wants to check on desired attributes they
> just aren't there.  The PyGTK stuff (gobject, glib, gtk, et al) yield
> similar complaints though perhaps for a different reason (they are
> implemented in C, so pylint can't build an ast to inspect *).
> 
> I'm not sure there's a good solution.  It would be nice to disable attribute
> checks in specific modules.  Sylvain suggested ignored-classes.  Is there an
> ignored-modules setting as well?

as I said, ignored-classes is misnamed. Actually this is a bit dumb, it's a 
list of "names" whose member access will be ignored. For instance with

  ignored-classes=gtk

access to gtk.Whatever won't be checked. There is also the generated-members
option used to specify members which are expected to be generated at runtime.
For instance with

  generated-members=aq_parent

access to self.aq_parent won't be checked, though access to self.whatever will.

As you said, even if things could be better, pylint won't ever be able to 
staticly divine what occurs at runtime. The best option I see is to be enhance
options like above and helpers like suggested below... Any suggestions on that
topics are welcome of course!

> *  Something just occurred to me.  It might be kind of useful to generate a
>    stub Python module from a C extension module.  Running something like
> 
>        generate-python-stub gobject gtk
> 
>    would cause the named modules to be imported and to the extent possible
>    generate stub modules in Python which mimic the structure of the
>    extension modules.  Pylint could then be directed to use those stub
>    modules.

yep, that's the kind of idea I've for http://www.logilab.net/org/ticket/2451

-- 
Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
Python et calcul scientifique:           http://www.logilab.fr/science


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.logilab.org/pipermail/python-projects/attachments/20081121/8688f838/attachment.htm