Black produced invalid code: assert (*x)

[dizzy57]

Operating system: macOS Mojave 10.14.5 (18F132)
Python version: Python 3.7.3
Black version: 19.3b0 (f3bb22a)
Does also happen on master: yes

Minified reproducer:

assert (*x)

Stack trace:

  File "black.py", line 3547, in assert_equivalent
    dst_ast = parse_ast(dst)
  File "black.py", line 3490, in parse_ast
    return ast27.parse(src)
  File "/Users/apreobrazhen/miniconda3/lib/python3.7/site-packages/typed_ast/ast27.py", line 51, in parse
    return _ast27.parse(source, filename, mode)
assert *x

This is invalid python code that gets accepted by blib2to3 grammar. I think black should throw InvalidInput exception in this case, not AssertionError.

Maybe it's worth raising an upstream bug for lib2to3?

[zsol]

I agree lib2to3 shouldn't accept this. There's a certain class of these python programs that are technically invalid python to start with, so Black is at a severe disadvantage of dealing with. I don't think this is super important to fix in Black as it will usually generate invalid code (like above) and then fail promptly.

I can't come up with an example that's all of:

• invalid python
• Black accepts it
• Black generates valid python at the end

This would be bad as Black would hide the fact that the original code was not valid Python and thus all bets are off, but as a user of Black it's very hard to tell there was an error in the first place.

[dizzy57]

I think it still would be nice to show a "Cannot parse" message instead of "INTERNAL ERROR, please report a bug".

[isidentical]

I agree with @zsol, there are numerous of examples where black can parse but CPython can't parse (or rather don't accept as input). The current error message seems to be better though:

 $ black -c "assert (*x)"                                                                                                                              19ms
assert (*x)
error: cannot format <string>: cannot use --safe with this file; failed to parse source file: can't use starred expression here (<unknown>, line 1)

[JelleZijlstra]

Thanks, closing as the current behavior seems fine.