-
-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
annotate command hits unicode happy fun time #363
Comments
Merged in lep/coverage.py (pull request #48) Fix #363: crash when annotating non-ascii characters in python 2. → <<cset 5544096a77fa (bb)>> |
Fix #363: crash when annotating non-ascii characters in python 2. → <<cset e0492ef9e320 (bb)>> |
Merged in lep/coverage.py (pull request #48) Fix #363: crash when annotating non-ascii characters in python 2. → <<cset 5544096a77fa (bb)>> |
Original comment by Vjacheslav Fyodorov (Bitbucket: fvabit, GitHub: Unknown) This fix crashes python 3 version in fedora 22. |
@fvabit Could you provide more details? |
Original comment by Vjacheslav Fyodorov (Bitbucket: fvabit, GitHub: Unknown) In python 3 line.encode('utf-8') produces bytes, not string, so we have:
I have reverted this line back, and all works fine. |
@fvabit Help me out here. Please provide complete details. What Python program were you measuring? What version of Python were you using? How did you run coverage? |
@fvabit it looks like you are running the pull request code, not the final code? Can you try the tip on bitbucket and see if it works for you? |
Original comment by Vjacheslav Fyodorov (Bitbucket: fvabit, GitHub: Unknown)
|
Original comment by Vjacheslav Fyodorov (Bitbucket: fvabit, GitHub: Unknown) Bitbucket code differs from my (which is from Fedora 22). Sorry. It should be updated in Fedora 22 distribution. |
Originally reported by Tom Callaway (Bitbucket: spotrh, GitHub: spotrh)
The annotate command chokes if unicode characters are parsed in the file. Here's a sample file (test.py):
It looks like the obvious fix is to force encode the line being written to utf-8, a patch is attached against 4.0a5 which does this. This resolves the issue in my testing, but I wanted to make sure I had it right first.
Note: I do not see this issue in the 3.7 code, only in 4.0.
The text was updated successfully, but these errors were encountered: