I have the following method
def foo(bar):
print("hello world")
Edit: Running pylint in VSCode
[expected behavior]
pylint highlights 'bar' as an unused variable
[Actual Behaviour]
From VScode output
##########Linting Output - pylint##########
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
I have no additional pylint config setup
It turns out there is a setting in VSCode that enforces minimal checkers
Python › Linting: Pylint Use Minimal Checkers
I found this in pylint documentation:
possibly-unused-variable (W0641):
Possibly unused variable %r Used when a variable is defined but might not be used. The possibility comes from the fact that locals() might be used, which could consume or not the said variable
In your case, probably because you haven't use the bar argument inside your function. If you are not using it, just remove it for a cleaning code.
Check the oficial VS Code documentation about linting if you want to change this settings.
Related
I was using pylint --list-msgs and one of the warnings I got was this one:
:using-final-decorator-in-unsupported-version (W2602): *typing.final is not supported by all versions included in the py-version setting* Used when the py-version set by the user is lower than 3.8 and pylint encounters a ``typing.final`` decorator.
I couldn't understand this warning because my version in .pylintrc and in the project is: 3.11, the only reference to typing in the project is this: from typing import TypedDict
I hope first is not receive this warning, because the project don't have reference with this warning, and if possible, understand the reason for the warning
When you launch pylint --list-msgs pylint is displaying a list of all its messages, it's going to always be the same for everyone and is not related to your code. Here's the doc for this message if you want more detail about it : https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/using-final-decorator-in-unsupported-version.html
I'm using vanilla Emacs and I installed lsp-mode as follows:
(use-package lsp-mode
:init
(setq lsp-keymap-prefix "C-c l")
:commands (lsp lsp-deferred)
:config (defun lsp-go-install-save-hooks ()
(add-hook 'before-save-hook #'lsp-format-buffer t t)
(add-hook 'before-save-hook #'lsp-organize-imports t t))
:hook (
(lsp-mode . lsp-enable-which-key-integration)
(go-mode . lsp-deferred)
(go-mode . lsp-go-install-save-hooks)
(typescript-mode . lsp-deferred)
(python-mode . lsp-deferred)
)
)
For Python I installed this. Everything seems to be working fine, but the problem is that I'm not able to override the default pycodestyle settings. For example, it complains about long lines > 79 so I tried adding in the root of the project the following setup.cfg:
[pycodestyle]
max-line-length=99
But it's not taken into account, am I missing something? I saw that there's the possibility to change the setting globally, but I'd like to have it on a per-project basis.
UPDATE
If pycodestyle is ran from the terminal it works as expected: it complains with the default line-length limit and it doesn't if I increase it to a value that is greater to the longest line that I have in the code.
The *lsp-log* buffer doesn't seem to provide any meaningful information:
Command "pyls" is not present on the path.
Command "pylsp" is present on the path.
Command "pyls" is not present on the path.
Command "pylsp" is present on the path.
Found the following clients for /<some path>/sample-app/sample_app/__init__.py: (server-id pylsp, priority -1)
The following clients were selected based on priority: (server-id pylsp, priority -1)
If I exec the flycheck-describe-checker command this is the output:
lsp is a Flycheck syntax checker.
This syntax checker checks syntax in the major mode(s)
`python-mode', `lsp-placeholder-mode', and uses a custom predicate.
Documentation:
A syntax checker using the Language Server Protocol (LSP)
provided by lsp-mode.
See https://github.com/emacs-lsp/lsp-mode.
If I disable flycheck by executing the command flycheck-disable-checker indeed the warnings go away, but it stops all the checks. So it seems like flycheck is the responsible for not honoring the setup.cfg.
I was able to understand what it seems to be happening. It seems that under the hood flycheck is using flake8 instead of pycodestyle. Indeed after I change setup.cfg into this:
[flake8]
max-line-length=99
Everything started working as expected.
The problem is that according to the documentation of python-lsp-server by default it should use pycodestyle. Moreover, checking through flake8 seems to be requiring 3rd party plugins according to the doc that I didn't install.
Not everything works as expected yet, as for example I have some complaints related to D100 and D104 that if I put them as ignore in the configuration their not honored yet.
I am using pylint for code linting (inside VS Code with pylint 2.3.1, astroid 2.2.5, Python 3.6.2).
The behavior can be reproduced with the following snippet:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from http import HTTPStatus
print(HTTPStatus.NOT_ACCEPTABLE.phrase)
Linting this snippet by calling
$ pylint snippet.py
gives the following error message:
E1101: Instance of 'NOT_ACCEPTABLE' has no 'phrase' member (no-member)
However, I think .phrase is a member of the given instance since the code is working, prints the desired result and .phrase is referenced in the docs. Which leads to the assumption that the error message is a false positive.
I then had a look at the pylint configuration options in its own documentation and in the VS Code docs and generated a .pylintrc file by executing
pylint --generate-rcfile > .pylintrc
Inside this configuration file I was able to find the following line:
enable=c-extension-no-member
Commenting out this line and thus disabling the c-extension-no-member checks, the false positive E1101 error message is suppressed. However, I am still wondering whether this is just a workaround or a real false positive, since it disables all c-extension-no-member checks and seems to be unsuitable for a general approach. For sure, one can specify specific modules to ignore on performing the checks, but I just want to know the reason for this error message.
For the following code
"""Test pylint on undefined variable"""
import random
def main():
"""Use undefined variable"""
if random.randint(0, 10) == 6:
thing = "hi"
print(thing)
if __name__ == '__main__':
main()
PyCharm correctly reports the problem.
pylint (2.0.0, Python 3.6.6) however does not recognize it:
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
But I would like it to find it, in order to let my CI fail in these cases.
So in fact I have two questions:
Is there an option for pylint to enable so that it can find this kindf of error?
What linting is PyCharm using by default? (I always thought it's pylint under the hood.)
Is there an option for pylint to enable so that it can find this kind of error?
Pylint is currently not able to detect possibly-undefined variables in a conditional or control flow block. A future version of Pylint may be able to recognize these kinds of errors. As of the time of your question, there is an open issue to add support for recognizing possible undefined variables inside of control flow blocks like your example.
Pylint does recognize variables that are definitely undefined before they are used, as in this example
print(x)
x = "Hello, world"
or this one
print(y)
if random.randint(0,10) == 3:
y = "ok"
What linting is PyCharm using by default? (I always thought it's pylint under the hood.)
PyCharm uses its own internal inspection library by default. PyCharm is implemented in Java and its inspection library is as well.
It is possible to use Pylint with PyCharm, but it is not built in or used by default. A solution for configuring Pylint as an external tool is shown here, and there is also a Pylint plugin for PyCharm available.
I use VS Code Version 1.19.3 with Python 2.7 on Windows.
Recently pylint (code analyzer) shown an error message
"E1601:print statement used"
But I don't know why! Can someone help me?
The print statement is correct as per my knowledge!
Is it a bug or a feature is missing?
Greetings niesel
The warning originates from Pylint, which is a very helpful tool for a dynamic language with loose syntax like Python. Since you are programming in Python 2.x where print is perfectly valid, I suggest you put a file in the root of your repo named .pylintrc and use it to configure Pylint.
To disable the print warning and leave everything else to the default, enter these two lines in your .pylintrc file:
[MESSAGES CONTROL]
disable=print-statement
You will also need to tell Visual Studio Code to use your configuration file by opening your workspace or user settings and add this:
{
"python.linting.enabled": true,
"python.linting.pylintEnabled": true,
"python.linting.pylintArgs": [
"--rcfile=/path/to/.pylintrc"
]
}
More options
To get a good idea of available configuration options open a terminal/prompt and run this command to generate a sample configuration file:
pylint --generate-rcfile > sample_pylintrc
The problem is, that changing from print statement to print function doesn't help much. So it seems, that it is some bug in VS Code Python module (2018.1 (01 Feb 2018)), as after this update I've found the same problem in my VS Code within my old projects
I've found reffered bug on their github
PS: vscode-python has changed pylint options since 2018.1. In order to return old behavior you may disable python.linting.pylintUseMinimalCheckers option for the workspace or for the userspace.
it's not an error per-se, it's just PyLint complaining about those legacy statements. PyLint will also complain about missing spaces before commas, those kind of style errors.
PyLint is there to warn you about possible problems. Your code will break when running python 3, so it warns you before it happens.
Note that print is a statement in python 2.x (which explains the message), and became a function in python 3.x.
Fix it by changing to:
print("test")
Since it's not a tuple, it works fine and does exactly the same for all versions of python, and PyLint will stop complaining.
you can also get rid of PyLint altogether: Windows 10 - Visual Studio Code - removing pylint (not sure if it's a good idea)