[New-bugs-announce] [issue34447] ttk.TreeView (and maybe other functions) is overzealous in converting item values to ints
report at bugs.python.org
Tue Aug 21 00:49:03 EDT 2018
New submission from Andrew Barnert <abarnert at yahoo.com>:
See this StackOverflow question for a repro case: https://stackoverflow.com/questions/51941260/
If you store a string that looks like an int in a TreeView's values, then call widget.item(row), the dict's 'values' value has that string converted to an int.
This seems reasonable, because it's legal to store an int in a TreeView, and if tkinter didn't convert the values, you'd store 123 and get back '123'.
However, I think it should only be converting strings that could be a valid Tcl int. If you store the int 123_456, Tcl of course gives you back '123456', not '123_456', so there's no reason for tkinter to convert '123_456' to an int. But it does, because ttk._tclobj_to_py just does a try: return int(s).
Maeanwhile, if you instead call widget.item(row, options='values'), the string is left alone.
At first glance, that made sense. But looking into what tkinter is getting back from Tcl, there's really no difference here. The tuple ('180518-23', '23/06/18') is no more or less conversion-worthy than the same tuple inside the list (<option object: '-text'>, '', <option object: '-image'>, '', <option object: '-values'>, ('180518-23', '23/06/18'), <option object: '-open'>, 0, <option object: '-tags'>, ''). It's just that ttk._val_or_dict doesn't call _tclobj_to_py on the value when it gets back a key-value pair, and I don't see why it shouldn't.
However, that turns out to be a handy workaround for the Stack Overflow user who ran into this problem, so maybe it's better not to change that.
title: ttk.TreeView (and maybe other functions) is overzealous in converting item values to ints
versions: Python 3.6, Python 3.7, Python 3.8
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce