Parser for TUCAN strings #74
Conversation
… testing the grammar
- black: exclude generated parser files - continue workflow even when black fails
|
I'll have a look this week, probably getting around to it on Friday. |
- The lexer rules TWO_TO_NINE and ONE_TO_NINE would cause conflicts, so count and node_index now use the digits as literals.
- improve rules for digits >= 1 and >1 again
- node properties 'MASS' and 'RAD' need to be lowercase to match the result of the serializer - roundtrip tests
…ception - test exception message - use f-strings
- add grammar in W3C EBNF and BNF Playground formats
…one level less of indirection
- remove debug print
| ], | ||
| ) | ||
| def test_parse_tucan_error_msg(tucan, expected_error_msg): | ||
| with pytest.raises(TucanParserException, match=expected_error_msg): |
There was a problem hiding this comment.
I'll change that in test_parser.py too ...
|
Finished with my first pass of the review. I haven't looked at the grammar definitions yet. Will be able to do so next week hopefully. |
- use list comprehension
|
Regarding the three grammar files, how do we make sure that when one is updated, the updates are propagated to the other two? I.e., it's conceivable that the three files become inconsistent because we forget to keep them in sync. Is there a way to use one grammar to automatically generate the other two? |
|
@flange-ipb, the grammar looks good to me (as far as I'm able to evaluate it without being familiar with the nitty-gritty). What about the failing round-tripping tests? Should we ignore them for now? If so, I'd approve and merge this PR. |
Indeed, that has to be done manually. I don't see any good option for automation. |
- roundtrip test: ignore failing tests
|
I think this is ready now. A few notes on the ignored graphs in the round-trip test:
|
@flange-ipb, see #47. |
closes #73