First thoughts on the proposal. I overall like it. The 'virtue' of the digit strings names is that they match tk behavior (I presume) and are consistently opaque ;-) *Someone* will object to change. Is your proposal to have (_)tkinter add a name= option when not provided by the user? The main problem I see is breaking code that assumes digits if no name= options are given. Is this currently guaranteed? 1. Canvas item ids are, in Python, ints (though I presume int strings in tcl) starting with 1. They number consecutively within canvas, regardless of 'type'. I wonder if tk uses them a indexes into an array of items for a particular canvas. I think I prefer sequential within class. Something else, I believe, generates alphanumeric names similar to what you propose. 2. Follow. 3. '#' seems a bit heavy, as it tends to overwhelm '.' as the separator. I think leave it out or use '-'. ".frame1.button2" or ".frame-1.button-2". I prefer without. These could be names I would give if I were to add name= options all over the place, except that it is too easy to reuse a number. Conflicts: tk does not prevent duplicate names by users. ... >>> entry2 <tkinter.Entry object .e1> >>> entry <tkinter.Entry object .e1> I am not sure of the consequence of this. The doc could say, "If you want widget names of the form <class-name(lowercased)><sequence number> either consistently supply them yourself with name= options, or let tkinter supply them for you."