-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
IDLE - Test hyperparser #65885
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
Comments
Test for idlelib.HyperParser |
Which lines are not hit? |
There are 7 scattered conditionals which only evaluate as one of True or False during tests and 5 lines not hit at all as a result. I am emailing instructions to install and use coverage package. |
Here are details how to trigger all of the uncovered code lines and branches, listed by line. Uncovered lines: Line 159: This catches would-be identifiers (variable names) which are keywords or begin with a character that can't be first (e.g. a digit). We should have at least one test for each of these cases. Lines 196-198: These strip comments from inside an expression. We should have a test with sample code with a multi-line expression with a comment inside it. Line 225: Triggered when trying to find an expression including parentheses or brackets when they aren't closed, e.g. "[x for x in ". Uncovered branches (except those which just cause the above): Lines 32, 42: To trigger, have a block of code over 50 lines long and create a HyperParser at the last line (not inside any other block). Line 236: Have a string literal inside brackets or parens, and call get_expression(). |
Regarding lines 32 & 42, a test could also set editwin.num_context_lines to allow triggering with smaller code blocks. It's value needs to be a list of integers, the last of which is incredibly large, perhaps sys.maxint. |
Since ParenMatch and fixes* to HyperParser depend on this issue, I would like to do this first. For HyperParser.py, I would like to first commit a clean-up only patch. The test_hyperparser patch should then only add the 'if __name__' clause at the end. I would like to apply the attached tomorrow, pending comments. It The v1 tests continue to pass once 'before the analyzed' is changed in the test file to 'precedes'. 'Index' or 'statement' might be better targets. *After test_hyperparser.py is added, additional tests for bpo-21756 (finding closers) and new bpo-21765 -- making HyperParser work with non-ascii identifiers, will be added as part of any code fix patches. |
New changeset 5063df721985 by Terry Jan Reedy in branch '2.7': New changeset ddf15cf0db72 by Terry Jan Reedy in branch '3.4': |
Coverage is now '99%'. Unless I see problems that are more than trivial, I am going to polish the patch and commit. I believe partial coverage of "for context in editwin.num_context_lines:" is because the iterable is never empty. But it never will be in practice and I believe the code is not intended to work if it is. So I ignore this. I believe partial coverage of deeply nested |
New changeset 59730aecce9b by Terry Jan Reedy in branch '2.7': New changeset 2fc89d2230a2 by Terry Jan Reedy in branch '3.4': |
Attached is the 3.4 patch as pushed. The main 'invisible' change, other than the review comment, was to create the code string just once. I discovered that the earlier version had a bug in saying 'ok' to the 3.x HyperParser bug of no longer recognizing 'False', etc, as identifiers due to being made keywords. The buggy test properly failed on 2.7. I did the easy fix and split the bad test into two. Since the 2.7 and 3.x versions of HyperParser were identical before the fix, the 3.x version must also not recognize the new ... Ellipsis literal. Tal, do you think doing so would be sensibly possible? (IE, would it be worth a new issue?) |
Ouch. I hadn't thought about the Ellipsis literal! That would be sensibly possible, yes, but not simple. I think opening a separate issue for this would be prudent. |
bpo-21787 Idle: make 3.x Hyperparser.get_expression recognize ... |
I forgot to mention that with this particular shutdown order |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: