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
IDLE: Add docstrings and unittests to outwin.py #74802
Comments
For bpo-30422. |
Questions about outwin.py:
Questions about tests:
Thanks! |
A1: yes, add I will have to think about whether and how to add an htest. The grep (find in files) test actually displays greps results in an outwin, and suggests rt clicking within the result window, so it really tests both grep and outwin modules. Maybe this htest should be split. A2. The current code tests whether the file exists *and* can be read. It must have been read to appear in grep output. But I am not sure this is true for names in tracebacks. B1. This is first test of an editor window. Having the least code, it it probably the best place to start and learn ;-). B2. The class level patterns are compiled to an instance array for each instance in which a user tries to go to file/line. That should be most. This looks to me like an attempted optimization (don't compile unless needed) that is a pessimization. I think either A) the compiled patterns should be stored back on the class or B) raw and compiled patterns should be stored at module level. They are not instance attributes and not really class attributes either. Also, the code blocks that create file_line_progs and use it really belong in module level functions. So lets try B. Move stuff from class to module scope: file_line_pats = [
...]
file_line_progs = None
def compile_progs():
global file_line_progs
file_line_progs = [re.compile(pat, re.IGNORECASE)
for pat in file_line_pats]
def find_file_line(line_of_text):
<body of current _file_line_helper, with 'self.' deleted>
# and simply method
def goto_file_line(self, event=None): # in class
if not file_line_progs:
compile_progs() Test for compile_progs (: Then feed find_file_line lines that should and should not match. Try to find at least 1 true-to-life line for each pattern. B3. In re, \d "matches any Unicode decimal digit (that is, any character in Unicode character category [Nd])". Builtin int (at least) accepts strings consisting of string literal, which is restricted to ascii digit. msg90878 says "int and float currently accept characters in category 'Nd'". I am not sure if that mean *all* Nd chars. We could test. If the exception is impossible, it should not be caught. (Dead code should be removed, but we must be sure it is dead ;-) |
Thanks! I've added more unittests. They are passing, but I'm getting a callback error that I don't understand. The same _utest flag that's on the textview dialog didn't seem to work and I was just blindly trying things without success. Also, the window is briefly opening and closing on the screen. Any suggestions on where I should look next? B3 below. Thanks for the link to that other message. Combining that with some comments on SO, I tried to find unicode that would be selected by \d and would fail with int(), but couldn't find any. However, I also realized that the try/except is checking for a TypeError and not a ValueError. I went and looked at the change history for OutputWindow, but couldn't see anything that would show why there might be a TypeError check here. If the match group is None, it wouldn't get this far in the code. Additionally,
Thanks! |
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: