path to problem file not reported when encoding declaration error occurs

Issue #514 resolved
Chris Jerdonek created an issue

When I tried running coverage run on a project for the first time, I got the following error. It seems like coverage should be reporting the path of the file it broke on to give users a better clue as to the source of the problem. This is with coverage 4.2 and Python 3.5.2: warning: No data was collected.
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/", line 392, in find_cookie
    line_string = line.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf5 in position 24: invalid start byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../bin/coverage", line 9, in <module>
    load_entry_point('coverage==4.2', 'console_scripts', 'coverage')()
  File "/.../lib/python3.5/site-packages/coverage/", line 753, in main
    status = CoverageScript().command_line(argv)
  File "/.../lib/python3.5/site-packages/coverage/", line 480, in command_line
    return self.do_run(options, args)
  File "/.../lib/python3.5/site-packages/coverage/", line 627, in do_run
    self.run_python_file(filename, args)
  File "/.../lib/python3.5/site-packages/coverage/", line 173, in run_python_file
    code = make_code_from_py(filename)
  File "/.../lib/python3.5/site-packages/coverage/", line 208, in make_code_from_py
    source = get_python_source(filename)
  File "/.../lib/python3.5/site-packages/coverage/", line 60, in get_python_source
    source = source.decode(source_encoding(source), "replace")
  File "/.../lib/python3.5/site-packages/coverage/", line 262, in _source_encoding_py3
    return tokenize.detect_encoding(readline)[0]
  File "/usr/local/lib/python3.5/", line 433, in detect_encoding
    encoding = find_cookie(first)
  File "/usr/local/lib/python3.5/", line 397, in find_cookie
    raise SyntaxError(msg)
SyntaxError: invalid or missing encoding declaration

Comments (11)

  1. Ned Batchelder repo owner

    @cjerdonek Can you provide me with a reproducible test case? The simple examples I'm making up show the bad filename in the traceback at least. I'm not sure how to get the behavior you are seeing.

  2. Chris Jerdonek reporter

    It was a while since I had used coverage, so my first attempt was:

    coverage run --source=bar <abs_path_to_python>

    Or something like that. From the error, I had no way of knowing the issue was with my invocation as opposed to any of the many Python modules being inspected for coverage. If the error had reported the filename of the Python executable, it would have been obvious and some time would be saved.

  3. Chris Jerdonek reporter

    Oh, we posted at the same time. My last comment shows that no source files are needed to generate the error.

  4. Ned Batchelder repo owner

    Oh, I see! This is a misunderstanding of how to use coverage. You don't need a path to python at all, which you now understand. I'm not sure if I added the path to the filename causing the error if most people would understand what to do about it...

  5. Chris Jerdonek reporter

    For both reporting issues and for personal troubleshooting, I think reporting the file name would be a big help. In this case, it would have said that the Python executable file lacked the encoding declaration, which would point the problem squarely at including the executable.

    And from a code / DRY perspective, it seems like wrapping the get_python_source(filename) call with an exception that reports the filename is a net win for everybody. If the filename is being reported for some exceptions and not others, it seems like there is an opportunity for coverage's code to be more DRY, etc.

  6. Log in to comment