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.