[New-bugs-announce] [issue32916] IDLE: change 'str' to 'code' in idlelib.pyparse.PyParse and users

[Terry J. Reedy]

New submission from Terry J. Reedy <tjreedy at udel.edu>:

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.

----------
assignee: terry.reedy
components: IDLE
messages: 312606
nosy: csabella, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: change 'str' to 'code' in idlelib.pyparse.PyParse and users
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32916>
_______________________________________