With pylint, is it possible to tell it to output warnings on lines that explicitly disable a particular warning, but where the warning doesn't actually occur?
The idea here would be that sometimes I'd like to clean up the suppression lines I added, after refactoring the code.
Now the obvious method would be to remove all suppression lines and then add them back one by one. But since pylint knows about the code and what I ask of it using suppression lines, it'd be better equipped to point out unnecessary suppression lines.
Can pylint do this?
I tried to search for this feature, but came up empty-handed. So I probably picked the wrong search terms.
I think you are looking for useless-suppression, as in pylint --enable=useless-suppression. It is disabled by default.
Related
I need to have this line in the beginning of a python file:
#script_exec_time: 500
There should not be any space between the # and script_exec_time. This is because the python file is parsed by another script and it will not consider the script_exec_time if there is a space.
I cannot modify the script that parses my python file because I do not have access to it.
Now when I lint using pylint, it automatically gives a space between the # and script_exec_time.
I tried using other linters like flake8, but even they do the same thing.
I still want to use the linter because it makes it much easier to code.
Is there any way to modify pylint settings so that it ignores comments from it's automatic formatting? Or is there any workaround I could use here?
Edit: I tried the same thing by disabling the linter. The problem persisted. It was not related to linter I think. Anyway I found a workaround and I am posting that as an answer.
As Vaibhav Vishal pointed out in his comment, linters like Pylint and flake8 do not reformat code, they just flag code that triggers a lint rule.
You most likely have a formatter installed and configured. See the formatting docs on how this is done and basically do the reverse. :)
All I did was to wrap the original comment in side a block comment, like so:
#script_exec_time:5000
'''
#scrript_exec_time:5000
'''
Vscode will not format anything that is there inside the block comments.
I am trying to enforce some simple python formatting rules. I found pylint and I have been very happy. However one of the more simple formatting checks I need to enforce is: tabs-only or spaces-only indentation.
In pylint, how do you enable errors or warnings for tabs or spaces indentation?
I see that pylint has w0311 "Used when an unexpected number of indentation's tabulations or spaces has been found". But w0311 does not enforce tabs-only or spaces-only... it still supports tabs or spaces.
I need all my python files to be only one type of indentation.
(
p.s. If you are curious how I use pylint to enforce my rules. I have a shell script that runs pylint and I use set -o errexit and this is hooked in with the build. So if pylint finds something it exits with nonzero value and causes the build to fail.
)
Well what you are looking for might be this:
mixed-indentation (W0312):
Found indentation with %ss instead of %ss Used when there are some mixed tabs and spaces in a module.
Which is raised when:
Description
Used when there are some mixed tabs and spaces in a module.
Explanation
Python interprets tabs and spaces differently, so consistent
indentation is critical to the correct interpretation of blocks in
Python syntax.
This warning is raised when a mix of both spaces and tabs is used in
indentation—or more precisely, when an indent is detected that is not
consistent with the indent-string option. By default, indent-string is
set to four spaces, the style of indentation recommended in PEP 8.
Edit #1:
Pylint does not have an option that I know of (and as of the moment) to "enforce" only tabs/spaces in your coding style. The above mentioned W0312 exists to warn for indentation inconsistencies on your code.
There is a trick that I use to enforce indentation: Open your project on PyCharm (works on the community edition also which is free) if the IDE detects inconsistencies it will warn you about them and it will give you an option to change indentation of the current file, or keep it as it is!
I am not a stickler for most things pep-8, but certain things I personally prefer when writing code (as opposed to for work, where I would adhere to the style or lack thereof of the existing code base).
One thing I personally tend to follow is pep-8's suggestion about blank lines:
Surround top-level function and class definitions with two blank
lines.
Method definitions inside a class are surrounded by a single blank
line.
However, I have not been able to get Pylint to warn me when I violate this. I don't see anything that seems relevant disabled in my .pylintrc, and I have not been able to figure out if this is possible in Pylint, and if so, how to enable it.
Based on this answer, it looks like there are certain aspects of pep-8 that Pylint does not (or did not at the time) cover, but I have not been able to ascertain whether this is the case for blank lines.
Is it possible to have Pylint warn about blank lines (too many/not enough) without writing custom extensions?
As mentioned in this other answer, E301 and E303 doesn't seem to be a thing in pylint (yet?).
One alternative would be to use the pycodestyle (previously: pep8) tool directly, which would allow you to check for blank lines.
Hopefully you'll like it as much as pylint, despite maybe being a little bit less configurable.
I am using PyDev with Eclipse and I have some attributes that are only set during runtime. Normally I can fix PyDev's errors like this:
obj.runtime_attr # #UndefinedVariable
However, since my statement is long and thus, with respect to PEP8, multiline, it looks like this:
some.long.statement.\
with.multiline(obj.runtime_attr).\
more()
Now I cannot add #UndefinedVariable because it breaks line continuation (PEP8 demands there are two spaces before a line-ending comment). However, I cannot put it in the end of the line (it just doesn't work):
some.long.statement.\
with.multiline(obj.runtime_attr).\
more() # #UndefinedVariable
Is there any way this could work that I am overlooking? Is this just a missing feature where you cannot get it right?
First, remember that the most important rule of PEP 8 is:
But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best.
And it specifically says to avoid a rule:
When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules.
That being said, you're already violating the letter and the spirit of PEP 8 just by having these lines of code, unless you can't avoid it without making things worse. As Maximum Line Length says, using backslash continuations is the least preferred way to deal with long lines. On top of that, it specifically says to "Make sure to indent the continued line appropriately", which you aren't doing.
The obvious way to break this up is to use some intermediates variables. This isn't C++; there's no "copy constructor" cost to worry about. In a real-life example (unlike this toy example), there are probably good names that you can come up with that will be much more meaningful than the long expression they replace.
intermediate = some.long.statement
multiline = intermediate.with.multiline(obj.runtime_attr)
more = multiline.more()
If that isn't appropriate, as PEP 8 explicitly says, it's better to rely on parenthetical continuations than backslash continuations. Is that doable here? Sure:
some.long.statement.with.multiline(
obj.runtime_attr).more()
Or, if worst comes to worst:
(some.long.statement.
with.multiline(obj.runtime_attr).more())
This sometimes makes things less readable rather than more, in which case you shouldn't do it. But it's always an option. And if you have to go to extraordinary lengths to make backslash continuation work for you, it's probably going to be worse than even the worst excesses of over-parenthetizing.
At any rate, doing things either of these ways means you can put a comment on the end of each line, so your problem never comes up in the first place.
I am developing using PyDev in Eclipse. I have put in some comments in my code. I get wavy red lines underneath certain words. The program runs fine and there are no warnings mentioned. So what is the meaning of these wavy lines.
e.g.
#!/usr/bin/python - I get the line under usr and python
# generated by accessing registry using another script written in VBScript.
# The scripts can do the follwing things.
- I get wavy lines under the words registry and following.
I need these comments as I may run the module on its own later.
Thanks for the help.
Neil speaks the truth, except for telling you to turn it off -- spell check in comments is quite helpful -- those who come after will thank you for ensuring they can read your comments without trying to decode random spelling errors.
The lines are simply pointing out words your IDE thinks are spelled wrong. I don't know why it doesn't understand "registry", but you have, in fact, misspelled "following" (as "follwing"). Fix the latter, ignore the former (or add it to the dictionary, don't remember if there's a convenient mechanism for that There is! See Macke's helpful comment below.).
Might be this is just a spellchecker. You have a typo "follwing" instead of "following".