Incorrectly identifying parens as superfluous in comprehensions with ternary operators

[MarkCBell]

Pylint incorrectly identifies parens as superfluous when they are used to isolate a ternary operator that determines the iterable inside of a list comprehension (or set comprehension, dict comprehension etc.).

Steps to reproduce

1. Create a file called scratch.py with contents:

""" A test script. """

print([i**2 for i in (range(10) if 7 > 5 else range(3))])

2. Evaluate this using the latest version of pylint:
   $ pylint scratch.py --enable=all

Current behavior

Pylint reports that there is one issue with this code:
scratch.py:3:0: C0325: Unnecessary parens after 'in' keyword (superfluous-parens)

Expected behavior

Pylint should report no issues with this code since the parenthesis are required. Following Pylints suggestion and changing the file to:

""" A test script. """

print([i**2 for i in range(10) if 7 > 5 else range(3)])

results in invalid Python code:

$ python scratch.py
  File "scratch.py", line 3
    print([i**2 for i in range(10) if 7 > 5 else range(3)])
                                            ^
SyntaxError: invalid syntax

pylint --version output

$ pylint --version
pylint 2.5.2
astroid 2.4.1
Python 3.8.1 (default, Mar  7 2020, 12:46:28)
[Clang 10.0.0 (clang-1000.10.44.4)]

[Pierre-Sassoulas]

Thank you for creating the issue, I can reproduce it on the latest pylint.

[brycepg]

I bisected this and I think it's from a combination of 716bcc4 and
a6d7ffc . The fix is non obvious because both those commits fixed other issues

[MarkCBell]

@brycepg so I'm not sure that those are the source of this bug. I think the error is triggered by this line https://github.com/PyCQA/pylint/blob/master/pylint/checkers/format.py#L421. It looks to me like there needs to be another block here https://github.com/PyCQA/pylint/blob/master/pylint/checkers/format.py#L436-L441 to handle the case where parens are required around a conditional statement. To ensure that statements like X = (5 if 5 > 7 else 1) are still flagged as superfluous this will likely require another found_if_else flag that is set if a ternary operator is encountered after an in.

[brycepg]

My bad I commented on the wrong issue