`pass` statements are removed causing syntax errors
BradLucky opened this issue · comments
Describe the bug A clear and concise description of what the bug is.
Under certain circumstances, pycln
will remove pass
statements, which can lead to syntax errors in code. As shown in the code snippet below, it has something to do with nested if
statements and that conclude with else: pass
.
I have trimmed the code down as much as possible to narrow in on the situations where this occurs. This does not appear to happen if there are not nested conditionals. Also, if there is not another assignment before the inner conditional, this also does not happen.
While this is example code, I am seeing this happening in production code.
To Reproduce Steps to reproduce the behavior:
-
Take this code snippet:
import os def cleaner(): if bool(True): no_thing = None if no_thing: pass else: pass else: pass
-
Run this Pycln command:
$ pycln test_file.py
-
Unexpected fixed code (if present):
Note: there are two empty lines preceding thecleaner()
method that are hidden by Githubdef cleaner(): if bool(True): no_thing = None if no_thing: pass else: pass else:
Expected behavior:
- I expected the
pass
statement to not be removed bypycln
unexpectedly. - Expected fixed code (if present):
def cleaner():
if bool(True):
no_thing = None
if no_thing:
pass
else:
pass
else:
pass
Environment (please complete the following information):
- Python Version: Python 3.9.6 and Python 3.10.1
- Pycln Version: v1.2.1
- OS Type: Linux, MacOS
I found another situation where this happens, and it's an even simpler case. If a new Exception
class is defined with a docstring and only pass
in the body (which is a very common use case), pycln
will remove the pass
from the class.
Input file:
import os
class CleanError(Exception):
"""Save me!"""
pass
Then run pycln test_error.py
and the file now looks like this:
class CleanError(Exception):
"""Save me!"""
It isn't strictly a syntax error in this case, but it's still a little disconcerting to have pycln
removing pass
in various places, when that has seemingly nothing to do with cleaning imports.
Hi @BradLucky, I see your point, I've fixed this bug via PR #100.
Thanks a lot for being around and supporting the project.