
Security News
PyPI Now Supports iOS and Android Wheels for Mobile Python Development
PyPI now supports iOS and Android wheels, making it easier for Python developers to distribute mobile packages.
Vulture finds unused code in Python programs. This is useful for cleaning up and finding errors in large code bases. If you run Vulture on both your library and test suite you can find untested code.
Due to Python's dynamic nature, static code analyzers like Vulture are likely to miss some dead code. Also, code that is only called implicitly may be reported as unused. Nonetheless, Vulture can be a very helpful tool for higher code quality.
--sort-by-size
$ pip install vulture
$ vulture myscript.py # or
$ python3 -m vulture myscript.py
$ vulture myscript.py mypackage/
$ vulture myscript.py --min-confidence 100 # Only report 100% dead code.
The provided arguments may be Python files or directories. For each directory Vulture analyzes all contained *.py files.
After you have found and deleted dead code, run Vulture again, because it may discover more dead code.
In addition to finding unused functions, classes, etc., Vulture can detect unreachable code. Each chunk of dead code is assigned a confidence value between 60% and 100%, where a value of 100% signals that it is certain that the code won't be executed. Values below 100% are very rough estimates (based on the type of code chunk) for how likely it is that the code is unused.
Code type | Confidence value |
---|---|
function/method/class argument, unreachable code | 100% |
import | 90% |
attribute, class, function, method, property, variable | 60% |
You can use the --min-confidence
flag to set the minimum confidence
for code to be reported as unused. Use --min-confidence 100
to only
report code that is guaranteed to be unused within the analyzed files.
When Vulture incorrectly reports chunks of code as unused, you have several options for suppressing the false positives. If fixing your false positives could benefit other users as well, please file an issue report.
The recommended option is to add used code that is reported as unused to a
Python module and add it to the list of scanned paths. To obtain such a
whitelist automatically, pass --make-whitelist
to Vulture:
$ vulture mydir --make-whitelist > whitelist.py
$ vulture mydir whitelist.py
Note that the resulting whitelist.py
file will contain valid Python
syntax, but for Python to be able to run it, you will usually have to
make some modifications.
We collect whitelists for common Python modules and packages in
vulture/whitelists/
(pull requests are welcome).
If you want to ignore a whole file or directory, use the --exclude
parameter
(e.g., --exclude "*settings.py,*/docs/*.py,*/test_*.py,*/.venv/*.py"
). The
exclude patterns are matched against absolute paths.
For compatibility with flake8, Vulture
supports the F401 and
F841 error
codes for ignoring unused imports (# noqa: F401
) and unused local
variables (# noqa: F841
). However, we recommend using whitelists instead
of noqa
comments, since noqa
comments add visual noise to the code and
make it harder to read.
You can use --ignore-names foo*,ba[rz]
to let Vulture ignore all names
starting with foo
and the names bar
and baz
. Additionally, the
--ignore-decorators
option can be used to ignore the names of functions
decorated with the given decorator (but not their arguments or function body).
This is helpful for example in Flask
projects, where you can use --ignore-decorators "@app.route"
to ignore all
function names with the @app.route
decorator. Note that Vulture simplifies
decorators it cannot parse: @foo.bar(x, y)
becomes "@foo.bar" and
@foo.bar(x, y).baz
becomes "@" internally.
We recommend using whitelists instead of --ignore-names
or
--ignore-decorators
whenever possible, since whitelists are
automatically checked for syntactic correctness when passed to Vulture
and often you can even pass them to your Python interpreter and let it
check that all whitelisted code actually still exists in your project.
There are situations where you can't just remove unused variables, e.g.,
in function signatures. The recommended solution is to use the del
keyword as described in the
PyLint manual and on
StackOverflow:
def foo(x, y):
del y
return x + 3
Vulture will also ignore all variables that start with an underscore, so
you can use _x, y = get_pos()
to mark unused tuple assignments or
function arguments, e.g., def foo(x, _y)
.
Raise the minimum confidence value with the --min-confidence
flag.
If Vulture complains about code like if False:
, you can use a Boolean
flag debug = False
and write if debug:
instead. This makes the code
more readable and silences Vulture.
See #216. For
example, instead of def foo(arg: "Sequence"): ...
, we recommend using
from __future__ import annotations
def foo(arg: Sequence):
...
You can also store command line arguments in pyproject.toml
under the
tool.vulture
section. Simply remove leading dashes and replace all
remaining dashes with underscores.
Options given on the command line have precedence over options in
pyproject.toml
.
Example Config:
[tool.vulture]
exclude = ["*file*.py", "dir/"]
ignore_decorators = ["@app.route", "@require_*"]
ignore_names = ["visit_*", "do_*"]
make_whitelist = true
min_confidence = 80
paths = ["myscript.py", "mydir", "whitelist.py"]
sort_by_size = true
verbose = true
Vulture will automatically look for a pyproject.toml
in the current working directory.
To use a pyproject.toml
in another directory, you can use the --config path/to/pyproject.toml
flag.
You can use a pre-commit hook to run
Vulture before each commit. For this, install pre-commit and add the
following to the .pre-commit-config.yaml
file in your repository:
repos:
- repo: https://github.com/jendrikseipp/vulture
rev: 'v2.3' # or any later Vulture version
hooks:
- id: vulture
Then run pre-commit install
. Finally, create a pyproject.toml
file
in your repository and specify all files that Vulture should check under
[tool.vulture] --> paths
(see above).
There's also a GitHub Action for Vulture and you can use Vulture programatically. For example:
import vulture
v = vulture.Vulture()
v.scavenge(['.'])
unused_code = v.get_unused_code() # returns a list of `Item` objects
Vulture uses the ast
module to build abstract syntax trees for all
given files. While traversing all syntax trees it records the names of
defined and used objects. Afterwards, it reports the objects which have
been defined, but not used. This analysis ignores scopes and only takes
object names into account.
Vulture also detects unreachable code by looking for code after
return
, break
, continue
and raise
statements, and by searching
for unsatisfiable if
- and while
-conditions.
When using the --sort-by-size
option, Vulture sorts unused code by its
number of lines. This helps developers prioritize where to look for dead
code first.
Consider the following Python script (dead_code.py
):
import os
class Greeter:
def greet(self):
print("Hi")
def hello_world():
message = "Hello, world!"
greeter = Greeter()
func_name = "greet"
greet_func = getattr(greeter, func_name)
greet_func()
if __name__ == "__main__":
hello_world()
Calling :
$ vulture dead_code.py
results in the following output:
dead_code.py:1: unused import 'os' (90% confidence)
dead_code.py:4: unused function 'greet' (60% confidence)
dead_code.py:8: unused variable 'message' (60% confidence)
Vulture correctly reports os
and message
as unused but it fails to
detect that greet
is actually used. The recommended method to deal
with false positives like this is to create a whitelist Python file.
Preparing whitelists
In a whitelist we simulate the usage of variables, attributes, etc. For the program above, a whitelist could look as follows:
# whitelist_dead_code.py
from dead_code import Greeter
Greeter.greet
Alternatively, you can pass --make-whitelist
to Vulture and obtain an
automatically generated whitelist.
Passing both the original program and the whitelist to Vulture
$ vulture dead_code.py whitelist_dead_code.py
makes Vulture ignore the greet
method:
dead_code.py:1: unused import 'os' (90% confidence)
dead_code.py:8: unused variable 'message' (60% confidence)
Exit code | Description |
---|---|
0 | No dead code found |
1 | Invalid input (file missing, syntax error, wrong encoding) |
2 | Invalid command line arguments |
3 | Dead code found |
Please visit https://github.com/jendrikseipp/vulture to report any issues or to make pull requests.
get_unused_code
and the fields of the Item
class (John Doknjas, #361).tests/**/*.toml
in sdist (Colin Watson).ruff
for linting and formatting (Anh Trinh, #347, #349).tox
by pre-commit
for linting and formatting (Anh Trinh, #349).--config
flag to specify path to pyproject.toml configuration file (Glen Robertson, #352).MagicMock
and Mock
(maxrake, #342).end_lineno
AST attribute to obtain more accurate line counts (Jendrik Seipp).--help
and --version
again (Jendrik Seipp, #321).UnicodeEncodeError
exception handling to core.py
(milanbalazs, #299).Enum
attributes _name_
and _value_
(Eugene Toder, #305).setup_module()
, teardown_module()
, etc. in pytest test_*.py
files (Jendrik Seipp).socketserver.TCPServer.allow_reuse_address
(Ben Elliston).--exclude
patterns are matched against absolute paths (Jendrik Seipp, #260).match
statement support (kreathon, #276, #291).__all__
as used (kreathon, #172, #282).pint.UnitRegistry.default_formatter
(Ben Elliston, #258).del
keyword to mark unused variables (sshishov, #279).locals()
(jingw, #225).getattr/hasattr(obj, "constant_string", ...)
as a reference to
obj.constant_string
(jingw, #219).x.some_name
but reading via
some_name
, at the cost of potential false negatives (jingw, #221).pyproject.toml
(Michel Albert, #164, #215).# type: ...
comments if on Python 3.8+ (jingw, #220).test
or tests
directories test files
(Jendrik Seipp).logging.Logger.propagate
attribute (Jendrik Seipp).__init__.py
(RJ722, #192).string.Formatter
(Joseph Bylund, #183).Constant
AST node under Python 3.8+ (#175).logging
module.sys.excepthook
to sys
whitelist.ctypes
module.--ignore-decorators
flag (thanks @RJ722).threading
module (thanks @andrewhalle).--ignore-names
flag for ignoring names matching the given glob
patterns (thanks @RJ722).--make-whitelist
flag for reporting output in whitelist format
(thanks @RJ722).--exclude
arguments on Windows.*-test.py
to recognized test file patterns.failureException
, longMessage
and maxDiff
to unittest
whitelist.while (True): ... else: ...
as unreachable (thanks @RJ722).argparse
instead of optparse
.async
function definitions (thanks @RJ722).Item.get_report()
method (thanks @RJ722).and
, or
and not
.scavenge()
and report()
.while
-conditions (thanks @RJ722).if
- and else
-conditions (thanks @RJ722).--min-confidence
flag (thanks @RJ722).return
, break
, continue
and
raise
(thanks @RJ722).object
(thanks @RJ722).FAQs
Find dead code
We found that vulture demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
PyPI now supports iOS and Android wheels, making it easier for Python developers to distribute mobile packages.
Security News
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.