-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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 tests for pyparse #77055
Comments
Add unit tests for pyparse.py in IDLE. |
I also moved existing comments in pyparse.py to be docstrings. Adding the tests revealed a bug in the initialization of self.lastopenbracketpos, but I didn't make any changes to fix it. With the bug, the tests weren't repeatable, so I modified the tests to work with the bug in place. |
Thanks for pointing out bpo-21765 - very interesting reading. :-) Would the new str.isascii() be helpful or would it be too early to use something only available in 3.7? It would seem that and combinations of |
Respone to msg312353: Yes, let us restrict this to testing pyparse code as is. I opened issue bpo-32880 for changing the code. My followup post discusses parse variable initialization. Putting instance variable defaults in class attributes is a known practice. But this is usually done when the 'default' is the most common value, not when the class attribute is always masked, before access, by an instance attribute of the same name. One could claim that it is buggy to not create a new Parser instance for each subtest. But the class appears to be designed for instance reuse, by having a separate set string method and by never looking at string-specific attributes until set from the string. We could instead say that the bug is the test checking an undefined value. I rejected the option of not looking when test.lastopenbracketpos is None and instead suggest on the new issue that this instance attribute always be freshly set, like all the others. |
Response to msg312428: I would generally prefer to put off using 3.x feature in module m until after we think we are done patching m for 3.(x-1), but do so before 3.x.0 release. When 3.x-1 went to security status a week after the 3.x release, this was not much an issue. In this case, we could use 'isascii' freely after Concrete code change proposals, including in hyperparser, should go on bpo-32880. In bpo-21765, I mentioned looking at ColorDelegator and UndoDelegator. I never did that, but added this to my list of possible issues. |
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: