You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
IDLE: change 'str' to 'code' in idlelib.pyparse.PyParse and users #77097
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:
assignee='https://github.com/terryjreedy'closed_at=<Date2018-02-24.05:21:23.629>created_at=<Date2018-02-23.00:56:01.409>labels= ['3.8', 'expert-IDLE', 'type-feature', '3.7']
title="IDLE: change 'str' to 'code' in idlelib.pyparse.PyParse and users"updated_at=<Date2018-02-24.05:21:23.628>user='https://github.com/terryjreedy'
Change 'str' to 'code' in pyparse and code that uses it. 'str' conflicts with the built-in name and it too general for 'the block of python code being processed'. 'code' is what the string is. The change applies to local 'str', 'self.str' references, and the 'set_str' method. The latter requires renames in other modules. From grep:
editor imports pyparse and calls Parser once in
y = pyparse.Parser...
and never references y.str
hyperparser imports pyparse and calls Parser once in
parser = pyparse.Parser...
and does reference the modifies parser.str once in line 67
self.rawtext = parser.str[:-2]
set_str is not called within pyparse itself
The existing pyparse tests are sufficient for pyparse since they execute every line containig 'str'. The hyperparser test covers the above lines in Hyperparser.__init__, but test_editor covers almost nothing and would miss the editor lines.
The two files access various methods and the editor code, the C_ constants, so I am not inclined to change names that are not so actively obnoxious.
Since this will impact other pyparse changes, I think it should be next. Cheryl, respond here if you want to do the PR.
Activity
terryjreedy commentedon Feb 23, 2018
Change 'str' to 'code' in pyparse and code that uses it. 'str' conflicts with the built-in name and it too general for 'the block of python code being processed'. 'code' is what the string is. The change applies to local 'str', 'self.str' references, and the 'set_str' method. The latter requires renames in other modules. From grep:
F:\dev\3x\lib\idlelib\editor.py: 1305: y.set_str(rawtext)
F:\dev\3x\lib\idlelib\editor.py: 1319: y.set_str(rawtext)
F:\dev\3x\lib\idlelib\hyperparser.py: 47:
parser.set_str(text.get(startatindex, stopatindex)+' \n')
F:\dev\3x\lib\idlelib\hyperparser.py: 63:
parser.set_str(text.get(startatindex, stopatindex)+' \n')
editor imports pyparse and calls Parser once in
y = pyparse.Parser...
and never references y.str
hyperparser imports pyparse and calls Parser once in
parser = pyparse.Parser...
and does reference the modifies parser.str once in line 67
self.rawtext = parser.str[:-2]
set_str is not called within pyparse itself
The existing pyparse tests are sufficient for pyparse since they execute every line containig 'str'. The hyperparser test covers the above lines in Hyperparser.__init__, but test_editor covers almost nothing and would miss the editor lines.
The two files access various methods and the editor code, the C_ constants, so I am not inclined to change names that are not so actively obnoxious.
Since this will impact other pyparse changes, I think it should be next. Cheryl, respond here if you want to do the PR.
csabella commentedon Feb 23, 2018
Yes, I agree. I'll start working on this one first.
terryjreedy commentedon Feb 24, 2018
New changeset c29c03a by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-32916: IDLE: Change
strtocodein pyparse (GH-5830)c29c03a
miss-islington commentedon Feb 24, 2018
New changeset f409c99 by Miss Islington (bot) in branch '3.7':
bpo-32916: IDLE: Change
strtocodein pyparse (GH-5830)f409c99
miss-islington commentedon Feb 24, 2018
New changeset cd2112f by Miss Islington (bot) in branch '3.6':
bpo-32916: IDLE: Change
strtocodein pyparse (GH-5830)cd2112f
terryjreedy commentedon Feb 24, 2018
Thanks. It is nice splitting the work this way.