Future imports aren't taken into account when checking syntax

[flyte]

This means that code like this will cause a SyntaxError:

from __future__ import print_function

def call_my_function(the_function):
    the_function("hi")

if __name__ == "__main__":
    call_my_function(print)

with output/traceback like so:

INTERNAL ERROR: 
    call_my_function(print)
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/flyte/dev/yapf/yapf/__main__.py", line 18, in <module>
    sys.exit(yapf.main(sys.argv))
  File "yapf/__init__.py", line 102, in main
    print_diff=args.diff)
  File "yapf/__init__.py", line 124, in FormatFiles
    filename, style_config=style_config, lines=lines, print_diff=print_diff)
  File "yapf/yapflib/yapf_api.py", line 68, in FormatFile
    print_diff=print_diff)
  File "yapf/yapflib/yapf_api.py", line 113, in FormatCode
    reformatted_source = reformatter.Reformat(uwlines)
  File "yapf/yapflib/reformatter.py", line 73, in Reformat
    verifier.VerifyCode(formatted_code[-1])
  File "yapf/yapflib/verifier.py", line 45, in VerifyCode
    compile(normalized_code.encode('UTF-8'), '<string>', 'exec')
  File "<string>", line 1
    call_my_function(print)
                         ^
SyntaxError: invalid syntax

The problem is that each line is taken on its own merit without taking into account imports from future.

[eliben]

Thank you for reporting this.

We're thinking what the best way to handle cases like this is, but in the meantime you can run yapf with --noverify on your code.

[flyte]

Is my solution in #54 workable? I'm happy to modify it if there's anything you'd like changed.

[eliben]

@flyte To be honest, I'm not sure. There are other ways verification can be tripped (in particular when dealing with the Python 2/3 boundary) and I'm not sure we want to engage in full-scale reparsing just for the sake of verification.

[flyte]

I thought that may be the case. I wasn't sure how important verification was, and without turning it off this seemed to me like the only way to fix the bug.

If you do end up going this way, then something I didn't implement was only scanning the beginning of the file since the 'from future import' lines must be before all other code. This would reduce the cost a fair bit.

[bwendling]

I commented in #54 about the code. IMHO, just adding from __future__ import ... statements when things don't work and seeing if they pass would be sufficient for the verifier module. :-)

[eliben]

Closing this, as verification is now disabled by default (starting with 7a01d00)

Please reopen if you still see this