fix(api): keep proto contents in bytes for longer #14446
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When we parse python protocols, we were doing it by (1) making it into a
string with decode('utf-8') and then (2) passing the string ast.parse().
The problem with this is that decode('utf-8') does not apply "universal
newlines", which means that the code object created by compiling the ast
will have line numbers that are around twice what they should be under
certain circumstances (windows machine, crlf file, mercury in the
seventh house, etc). Then, when we go and display a nice error message
about a syntax error or whatever, the user says "why is this error
message pointing to a place past the end of my protocol".
This should fix that by keeping the protocol contents in bytes form all
the way through to passing ast.parse() a bytes that _has never been
through str.decode('utf-8')_ which should preserve everything.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## chore_release-7.2.0 #14446 +/- ##
=======================================================
- Coverage 68.10% 68.03% -0.08%
=======================================================
Files 2518 2518
Lines 72031 72027 -4
Branches 9245 9245
=======================================================
- Hits 49059 49003 -56
- Misses 20770 20822 +52
Partials 2202 2202
Flags with carried forward coverage won't be shown. Click here to find out more.
|
SyntaxColoring
approved these changes
Feb 9, 2024
TamarZanzouri
pushed a commit
that referenced
this pull request
Feb 16, 2024
When we parse python protocols, we were doing it by (1) making it into a
string with decode('utf-8') and then (2) passing the string ast.parse().
The problem with this is that decode('utf-8') does not apply "universal
newlines", which means that the code object created by compiling the ast
will have line numbers that are around twice what they should be under
certain circumstances (windows machine, crlf file, mercury in the
seventh house, etc). Then, when we go and display a nice error message
about a syntax error or whatever, the user says "why is this error
message pointing to a place past the end of my protocol".
This should fix that by keeping the protocol contents in bytes form all
the way through to passing ast.parse() a bytes that _has never been
through str.decode('utf-8')_ which should preserve everything.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we parse python protocols, we were doing it by (1) making it into a string with decode('utf-8') and then (2) passing the string ast.parse(). The problem with this is that decode('utf-8') does not apply "universal newlines", which means that the code object created by compiling the ast will have line numbers that are around twice what they should be under certain circumstances (windows machine, crlf file, mercury in the seventh house, etc). Then, when we go and display a nice error message about a syntax error or whatever, the user says "why is this error message pointing to a place past the end of my protocol".
This should fix that by keeping the protocol contents in bytes form all the way through to passing ast.parse() a bytes that has never been through str.decode('utf-8') which should preserve everything.
Testing
flex_mag_mod.py.zip (unzip it first) that has (1) an error and (2) crlf newlines
opentrons_simulateand in the app