6 ms·

>> configure it with a whitelist of lint checks I have found Pylint to be very helpful, and always use it on Python projects past the size of a short script.

>> configure it with a whitelist of lint checks I have found Pylint to be very helpful, and always use it on Python projects past the size of a short script. If you start using Pylint at the beginning of a project, you can blacklist warnings that you want to ignore fairly easily.

guitarbill 10y ago
Agreed. I mean you don't need to follow it religiously, but it's pretty workable with a small blacklist (docstrings, locally disabled, and a few more I don't instantly recall). When the hacks get bad, maybe the odd `#pylint: disable=<blah>` but at least it shows you've though about the pylint warning. >> If the errors are utter garbage, delete those checks from the configuration. I've never had "utter garbage" errors. I've had errors I didn't agree with/made the conscious choice to ignore. And I've had errors I thought were garbage, but really I just didn't fully understand them. (Although I've experienced how applying it to an existing, unlinted project is horrible.)
- _Wintermute 10y ago
  >> I've never had "utter garbage" errors. I've had errors I didn't agree with/made the conscious choice to ignore. And I've had errors I thought were garbage, but really I just didn't fully understand them. I've had lots of spurious errors with numpy code, where pylint seems to think everything is a list.
  - guitarbill 10y ago
    I've experienced something similar with SQLAlchemy, because of the amount of auto-magical stuff it does. I solved it with `[TYPECHECK] generated-members=query`, although this can be slow so blacklisting SQLAlchemy classes is still an option. NumPy's `__init__.py` code is a bit messy and manipulates `__all__` a lot [0], so I can understand why pylint (and other static code analysis tools) struggle with it. Yeah, it's frustrating hitting errors in third party modules, and it's tedious for one person initially to set up pylint correctly, but so worth it for a team. [0] https://github.com/numpy/numpy/blob/master/numpy/__init__.py#L183 https://github.com/numpy/numpy/blob/master/numpy/__init__.py...

guitarbill 10y ago

Agreed. I mean you don't need to follow it religiously, but it's pretty workable with a small blacklist (docstrings, locally disabled, and a few more I don't instantly recall). When the hacks get bad, maybe the odd `#pylint: disable=<blah>` but at least it shows you've though about the pylint warning. >> If the errors are utter garbage, delete those checks from the configuration. I've never had "utter garbage" errors. I've had errors I didn't agree with/made the conscious choice to ignore. And I've had errors I thought were garbage, but really I just didn't fully understand them. (Although I've experienced how applying it to an existing, unlinted project is horrible.)

_Wintermute 10y ago
>> I've never had "utter garbage" errors. I've had errors I didn't agree with/made the conscious choice to ignore. And I've had errors I thought were garbage, but really I just didn't fully understand them. I've had lots of spurious errors with numpy code, where pylint seems to think everything is a list.
- guitarbill 10y ago
  I've experienced something similar with SQLAlchemy, because of the amount of auto-magical stuff it does. I solved it with `[TYPECHECK] generated-members=query`, although this can be slow so blacklisting SQLAlchemy classes is still an option. NumPy's `__init__.py` code is a bit messy and manipulates `__all__` a lot [0], so I can understand why pylint (and other static code analysis tools) struggle with it. Yeah, it's frustrating hitting errors in third party modules, and it's tedious for one person initially to set up pylint correctly, but so worth it for a team. [0] https://github.com/numpy/numpy/blob/master/numpy/__init__.py#L183 https://github.com/numpy/numpy/blob/master/numpy/__init__.py...