Closed jvavrek closed 8 months ago
this was intentionally changed at some point. there are a few cases where it still leaves an else less one but when it deems it safe it can
this was intentionally changed at some point. there are a few cases where it still leaves an else less one but when it deems it safe it can
Is it intentional that the behavior differs between the pre-commit hook and the command line, though?
Similarly, is it intentional/safe that it deletes the next comment?
you are comparing 3.3.1 vs 3.15.0 what do you expect?
you are comparing 3.3.1 vs 3.15.0 what do you expect?
Ok, if I update my local pyupgrade
to 3.15.0, I get consistent behavior between the two---both delete the if
block. However I still submit that there are two issues:
pyupgrade
incorrectly deletes the next comment after the if sys.version_info
blockthe end of the block is not well defined when there's trialing comments -- pyupgrade picks the approach based on the information the tokenization hands it -- there isn't a correct choice because people do all sorts of flavors of:
if ...:
code
# comment
etc.
the docs aren't really out of date since there are still cases where it will leave an elseless branch alone -- but enumerating them in the docs isn't useful
the case the docs is specifically referring to (where it will introduce a syntax error) is:
if True:
if sys.version_info ...:
...
Fair points, thanks.
In the section on Python2 and old Python3.x blocks, the README states:
However I have noticed that some of my else-less if blocks for checking old Python versions get deleted by the
pyupgrade
pre-commit
hook.Minimal steps to replicate:
Not only does the
pre-commit
hook rewrite (delete) theif
block unexpectedly, it also deletes the next comment (# run setup
)! As a result, mytest.py
afterpre-commit
looks likewhere the remaining comment now pertains to the wrong line of code.
Version info: pyupgrade 3.3.1 pre-commit 2.20.0 python 3.9.13