FWIW, I have patches to de-lint bitwise_grammar.py and bitwise.py, and I think the changes are uniformly beneficial to the code.
It's not the bitwise code itself, but the code that uses it that is likely most probematic.
The most widespread problem has been the lack of docstrings. Maybe it has matured since you last used it?
I use it almost every day, so, no. There are aspects of python that cannot be statically analyzed -- it's part of the nature of the thing. For example:
class Test(object): def __init__(self, value): setattr(self, 'test_attribute', value)
t = Test() print t.test_attribute
yields this:
E: 6, 6: Instance of 'Test' has no 'test_attribute' member (no-member)
Bitwise is full of that sort of stuff by nature. It's one of the most useful things that pylint can do (identifying things that a compiler would have caught, like using non-existent identifiers), yet it's going to fail miserably on any code that uses bitwise (read: almost all of chirp).
It gets a solid endorsement from me, because it has already flagged some real errors in the code that need to be fixed. Indeed, I was originally skeptical that it would be worthwhile, since we already comply with pep8; however, these results made me think that it can be tuned to yield significant ongoing value for this project.
I'd rather you just write unit tests for things like your logger module and catch the issues that way. Further, like pep8, pylint is a moving target and keeping the config file up to date such that it continues to run on newer versions is actual work, and not work I personally want to do.
--Dan