Error when choosing rename option after editing tuple value from Variable explorer.

[syedshakeel]

Description

What steps will reproduce the problem?

tup = 123,'abc', 235, (2,3,5)
tup = tup + ('a', 'b')
2.
From Variable explorer - Edit the tup variable.
3.
Choose Rename and it will thru an error

What is the expected output? What do you see instead?

Please provide any additional information below

File "C:\Users\S381753\Python\Anaconda3\lib\site-packages\spyder\widgets\variableexplorer\collectionseditor.py", line 972, in rename_item
self.copy_item(True)
File "C:\Users\S381753\Python\Anaconda3\lib\site-packages\spyder\widgets\variableexplorer\collectionseditor.py", line 955, in copy_item
QLineEdit.Normal, orig_key)
TypeError: getText(QWidget, str, str, echo: QLineEdit.EchoMode = QLineEdit.Normal, text: str = '', flags: Union[Qt.WindowFlags, Qt.WindowType] = Qt.WindowFlags(), inputMethodHints: Union[Qt.InputMethodHints, Qt.InputMethodHint] = Qt.ImhNone): argument 5 has unexpected type 'int'

Version and main components

• Spyder Version: 3.2.4
• Python Version: 3.6.3
• Qt Versions: 5.6.2, PyQt5 5.6 on Windows

Dependencies

pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.20.3 (OK)
numpy >=1.7      :  1.13.3 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
rope >=0.9.4     :  0.10.5 (OK)
jedi >=0.9.0     :  0.10.2 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
sympy >=0.7.3    :  1.1.1 (OK)
cython >=0.21    :  0.26.1

[CAM-Gerlach]

Thanks for reporting. I've reproduced the apparent bug, minimized even further:

1. Create a built in Python object with more than one element that can be opened in a separate edit window in Variable explorer, confirmed on a list and a tuple (possibly others)
2. Doubleclick/edit "foobar" in Variable explorer.
3. Then, right click anywhere, on anything, and select "Rename" or "Duplicate", and the above error occurs.

However, renaming etc works fine on any of those objects when done on the parent object, from the main variable explorer window, which I assume is what you are intending to do, so at least until this is fixed you can simply do that with no loss in actual functionality.

Therefore, it seems that either "Rename" and "Duplicate" should be disabled in the contextmenu when within variable explorer sub windows, as those commands do not (and, likely cannot) function properly on the sub elements (i.e. indicies) of most parent objects, or within that window they should still act on the parent object (more functional, but perhaps more confusing/inconsistent). @ccordoba12 would be able to respond more authoritatively to this.

[Prikers]

@ccordoba12 renaming within a collection editor offers the user the possibility to break the data model: for example within the editor of l = [1, 2] I could choose to rename the last row into, say, 99. But for a list the model is stored as a list (!) and the keys are the indexes. Renaming means adding new keys. In my previous example it brings a question:

• should we validate that the input key is ok (so nok in my example)?
• should we not show the rename option for lists?

[CAM-Gerlach]

@Prikers Out of curiosity, what would be the practical use of doing so, given the limitations you mention? Also, probably restating the obvious, but the latter choice (disabling the rename and duplicate options) would presumably be what should happen for tuples regardless.

Also, on a tangentially related note, mucking around with a tuple in the Variable Explorer actually lets me edit (rather than just select, copy etc) its values when the text box is active, but the changes don't stick (of course). Presumably, the text should be selectable, but not editable, to match the immutability of the data type—I would imagine this would just be some property of the textbox Qt object that needs to be set, or something like that?

[ccordoba12]

should we not show the rename option for lists?

I think that's the simplest option, yep.

[ccordoba12]

Presumably, the text should be selectable, but not editable, to match the immutability of the data type

Right, I agree with this one too.

[Prikers]

Presumably, the text should be selectable, but not editable, to match the immutability of the data type

I agree with that! Should it be a different issue/PR though?

Out of curiosity, what would be the practical use of doing so

I cannot see any but I wanted to make sure I was not missing something 😄