pycqa / eradicate

Removes commented-out code from Python files

eradicate

---

eradicate removes commented-out code from Python files.

Introduction

With modern revision control available, there is no reason to save commented-out code to your repository. eradicate helps cleans up existing junk comments. It does this by detecting block comments that contain valid Python syntax that are likely to be commented out code. (It avoids false positives like the sentence this is not good, which is valid Python syntax, but is probably not code.)

Example

$ eradicate --in-place example.py

Before running eradicate.

#import os
# from foo import junk
#a = 3
a = 4
#foo(1, 2, 3)

def foo(x, y, z):
    # print('hello')
    print(x, y, z)

    # This is a real comment.
    #return True
    return False

After running eradicate.

a = 4

def foo(x, y, z):
    print(x, y, z)

    # This is a real comment.
    return False

Whitelisting

False positives can happen so there is a whitelist feature to fix them shorthand. You can either add entries to the default whitelist with --whitelist-extend or overwrite the default with --whitelist. Both arguments expect a string of # separated regex strings (whitespaces are preserved). E.g. eradicate --whitelist "foo#b a r" filename Those regex strings are matched case insensitive against the start of the comment itself.

For the default whitelist please see eradicate.py.

Related

There are different tools, plugins, and integrations for eradicate users:

• flake8-eradicate - Flake8 plugin to find commented out or dead code.
• databricks-labs-pylint - Databricks-specific PyLint plugin, that can also find commented out code.

eradicate's Issues

eradicate and black

Repost of wemake-services/flake8-eradicate#8.

Hi,

Thanks for the tool. Unfortunately, eradicate recognizes # fmt: on and # fmt: off as commented out code whereas the comments identify blocks which should not be formatted with black. Is it possible to exclude these patterns?

Best

Is it time to issue a new release?

# mypy: disable-error-code = misc

At the moment comment like this would be considered an error.

Usually, users forced to write such comments because of typing.Any was used inside third-party library imported by the users code. For example, it's a problem with popular FastAPI and Typer frameworks when you have strict mypy setting that even expression inside a function can't be evaluated to Any. So, it's kinda annoing.

That was already fixed in the upstream branch.

It would be nice to make it available on PyPI.

Thoughts?

Best regards,
Josiah.

Type ignore comments is a false positive.

Write # type: ignore at the beginning of the file will be considered by this plugin as dead code.

Initially reported to wemake-services/flake8-eradicate#68

Add "EXAMPLE" to whitelist

Could you please add "EXAMPLE" to the built-in whitelist? This would allow to have some code examples as comments.

False positive for `# type: ignore[override]`

Eradicate raises for this comment, which should be perfectly valid.
Because it is a special syntax for mypy types.

Use of mutation testing in eradicate - Help needed

Hello there!

My name is Ana. I noted that you use the mutation testing tool mutpy in the project.
I am a postdoctoral researcher at the University of Seville (Spain), and my colleagues and I are studying how mutation testing tools are used in practice. With this aim in mind, we have analysed over 3,500 public GitHub repositories using mutation testing tools, including yours! This work has recently been published in a journal paper available at https://link.springer.com/content/pdf/10.1007/s10664-022-10177-8.pdf.

To complete this study, we are asking for your help to understand better how mutation testing is used in practice, please! We would be extremely grateful if you could contribute to this study by answering a brief survey of 21 simple questions (no more than 6 minutes). This is the link to the questionnaire https://forms.gle/FvXNrimWAsJYC1zB9.

Drop me an e-mail if you have any questions or comments ([email protected]). Thank you very much in advance!!

Misses methods declaration with annotated return types

Hi, thanks for this awesome plugin. I am using it in production, it works great.
However, I have found out that it misses this case:

-# class CommentedClass(object):
 #     def __init__(self, prop: int) -> None:
-#         self.property = prop
 
 #     def __str__(self) -> str:
-#         return self.__class__.__name__
 
-#    def set_prop(self, prop: int):
-#        self.prop = prop
 
-#    def get_prop(self):
-#        return self.prop

Look, all method declarations with annotated return types are ignored in this diff. The same goes for the regular functions, not just methods.
This may lead to some false negative behavior.

P.S. I have made a flake8 plugin to check my codebase with eradicate, check it out: https://github.com/sobolevn/flake8-eradicate

coala

Hi,

I thought you might want to be aware that we're using eradicate for coala (see coala-analyzer.org), the functionality gets added in coala/coala#1041 .

Because of that we rely on your public but undocumented API filter_commented_out_code.

With this you can use eradicate right in several editors, via an interactive CLI, get JSON output or use the gitmate service we're building (gitmate.com - prototype!).

If you're interested, we could work on moving your analysis routines over to coala natively, we could make a coala CLI application that simply applies the patches automatically without user interaction, so you would get our user interaction while we would maintain the algorithms for you if they're part of our project. They may also then be reused for other programming languages as far as possible.

Commented out code not detected when code block is two lines long

Copied from wemake-services/flake8-eradicate#265:

If you paste the following code into a new file, flake8-eradicate will only detect the first and the third code blocks. The second block, split over two lines is not detected.

# create_output_path(*os.path.split(mypath),
#                    overwrite=overwrite,
#                    exist_ok=True)

# create_output_path(*os.path.split(mypath), overwrite=overwrite,
#                    exist_ok=True)

# create_output_path(*os.path.split(mypath), overwrite=overwrite, exist_ok=True)

Repro steps

$ python3.8 -m venv ~/deleteme
$ source ~/deleteme/bin/activate
$ pip install flake8-eradicate
$ flake8 test.py --max-line-length=81

Expected result

Commented out code found on lines 2-4, 6-7, and 9.

Actual result

test.py:3:1: E800 Found commented out code
test.py:9:1: E800 Found commented out code

False positive on TODO or XXX marks comments

Code like # TODO: test or # XXX: test is mistakenly recognized as commented out code.

Issue is similar to #15 and #11.

Exit code when errors are found

Hi,
I would like to use this on tox so if it finds errors the test should fail.

At the moment it doesn't work as eradicate always returns a 0 as exit code.

Allow doctest in the comments.

Some times it's useful to explain implementation details of the function with usage examples in the comment.

I propose to allow doctest prefixed code in the comments.

What do you think?

Have a good day 🎉

Best regards,
Artem.

Configuration file

Hello,

if a user doesn't want to use flake8, the only option to provide configuration is to use the command line. Would it be possible to add support for a configuration file (e.g. pyproject.toml)?

Regards,
Kai

misses withs and fors

         # with open('filename', 'w') as outfile:
-        #     json.dump(objects, outfile)
         #

     # for x in y:
-    #     foop = x.ham

Upload wheels to PyPI

Wheels (.whl) for this package are currently missing from PyPI. Could wheels be uploaded for the current and future releases?

Read more about the advantages of wheels to understand why generating wheel distributions are important.

To create a wheel along with source distribution:

(venv) $ pip install --upgrade pip setuptools wheel
(venv) $ python setup.py sdist bdist_wheel

# See dist/*.whl

To upload wheels:

(venv) $ pip install twine
(venv) $ twine upload dist/*

Add test cases for python3.7 and python3.8

Currently travis.yml does not support latest python versions.

I can send a PR with the fix!

Related: wemake-services/wemake-python-styleguide#1138

Add whitelist feature

I came here from flake8-eradicate because of a false positive which already has an issue.

Then I saw there are several different false positives (as of now 5/7 open issues):

• #25
• #24
• #16
• #15
• #11

Wouldn't it be the easiest to add a whitelisting feature?

False Positives

Hi, I've tried eradicate on the coala project and it came up with only false positives. Here's a visualization of the results: http://pastebin.com/qbfg1Ecc (I assure you it's the latest eradicator release from pypi working behind the scenes, just think this is better to read and contains diffs with context so you can see whats going on.)

Especially if there's code between noncode lines I think it makes sense to exclude them, also there's a false negative in cindex.py which would be nice to have handled, I think something starting with a bracket may be easily declared as positive?

Various non-code comments removed

I just tried out eradicate, and it removed those comments which aren't sourcecode:

• # See # https://github.com/The-Compiler/qutebrowser/issues/263
• # Qt >= 5.4 (okay, this one is probably hard to detect)
• # anything (yet)
• # configparser can't handle = in keys :(

False positive for `# pyright: reportSomeError=...`

PyRight is a static type checker similar to mypy and pyre from Microsoft.
Errors in PyRight can be ignored on a per-line basis, similar to mypy, using the comment style

# pyright: reportErrorName=[false|true].

either at the end of the line causing the error or on the line above it.

These are falsely being flagged as commented out code by eradicate. It would be nice if this can be fixed.

I'd be happy to put up a PR for this with some guidance.

eradicate seems to think the python-encoding-declaration is a source comment

example would be something like

# coding=utf-8

import os
os.whatever()

(declaration follows PEP263)

Location of commented code is incorrect

Eradicate seems to highlight the first character of the first line as the offending source location. This makes eradicate less useful when used within an editor as it's often not obvious that there are errors.

It would be great if Eradicate supported giving a correct, or roughly correct, location of the offending source location.

Drop Python2 support

Right now almost no users are on Python2: https://pypistats.org/packages/eradicate

And it is long gone.
I propose to drop it, because even actions-python won't support it soon.

Python2 users can continue using 2.2 and 2.3