I have to disagree rather strongly with closing this as "not a bug".  If the issue really boils down to incorrectly passing a single string when there is only one item in 'values', and a single-item tuple should be used instead, then shouldn't the better solution be for Python to handle this automatically and re-cast the errant string into a tuple?

My example indicates a case of where I got the Tcl interpreter itself to choke on invalid user input.  Even though the tkinter binding module catches the exception from the Tcl interpreter, I think it's Python's job as the wrapping language to catch any user stupidity done in Python and try to work around it if it's simple to do so.  A user coding against Tkinter/Ttk should not be required to have or need knowledge of Tcl/Tk itself to code a GUI.  That knowledge certainly helps, but not having it is one of Python's selling points for using Tkinter in the first place.

I have a coding project where I initially tripped up the semi-colon issue while parsing data from a text file into a Treeview widget (in listbox mode), that has a single-column.  The data being parsed included quoted regular expression syntax.  The function doing the parsing passed the parsed data to another function that populated the Treeview using **kwargs to send "values" and "tags" to Treeview's "insert" method.  It was a backslash character in the quoted regular expression string, at a point before the semi-colon, that eventually goofed the Tcl interpreter up, but //only// when passed in via **kwargs syntax.

The original code was too complex to replicate for the bug, so I reduced things down to a smaller testcase.  During this, I inadvertently tripped up the other bug with the unmatched open quote error, so I reported both.

My current workaround involves scanning the input for a backslash character or a whitespace character (which also trips things up), and if found, wrap the string in curly braces, which disables Tcl's substitution mechanism for that string, then calling Treeview's "insert" method.  It's more complicated this way, but safe for dealing with regular expression strings as possible input.