Multiple issues with false positives motivated me to add a whitelisting feature.

You can extend the default whitelist or overwrite it from command line. Whitelist entries are interpreted as regex.

WHITELIST = [
    r'pylint',
    r'pyright',
    r'(?i)noqa',
    r'type:\s*ignore',
    r'fmt:\s*(on|off)',
    r'TODO',
    r'FIXME',
    r'XXX'
]

Currently the regex check is case sensitive. A single entry can be made case insensitive by adding (?i) like above for noqa.

Maybe case insensitivity by default is okay? What other defaults do you know that should be added?

I'm currently working on the tests and will also update the README afterwards.

Closes #19 PR for manually ignoring TODO which is covered by this PR

Fixes #25 Fixes #24 Fixes #16 Fixes #15 Fixes #11 Resolves #26

EDIT: Please see comment(s) below

Repost of https://github.com/sobolevn/flake8-eradicate/issues/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

Like requested in #33 (comment) here is a translation of the travis config in GHA.

I updated the tested python versions with additional ones and kept the rest as it was.

EDIT: I do not intend to rewrite the config to a proper GHA config. Reason see: https://github.com/myint/eradicate/pull/33#issuecomment-1086034653

This PR aims to follow PEP 263 more precisely, especially for source code encoding hints. According to PEP 263, encoding hints allow the following regular expression:

^[ \t\f]*#.*?coding[:=][ \t]*([-_.a-zA-Z0-9]+)

The regexp match # encoding: utf8 which I often use but eradicate 0.2.1 considered that the line contains code.

$ eradicate tmp.py
 #!/usr/bin/python
-# encoding: utf8

...

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

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?

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/*

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

Initially reported to https://github.com/sobolevn/flake8-eradicate/issues/68

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 :(

as distutils will be deprecated in python 3.12 and already produces a warning when run with python 3.10.x, it might be a good time to switch to setuptools. It offers the same interface, so results will be the same

Signed-off-by: Konrad Weihmann [email protected]

Integrates pre-commit with eradicate. This makes it easy to configure and add eradicate as a pre-commit hook in your git repo.

For example, the nbstripout repo just merged a similar hook for that tool (for example in PR 79).

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!!

Copied from https://github.com/wemake-services/flake8-eradicate/issues/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

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

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 :tada:

Best regards, Artem.

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.