Maybe this isn't an issue for the quantity of data you're dealing with, but as a rule, widgets tend to impose a cost in terms of memory and cpu overhead -- the more widgets, the slower the GUI, especially if you're talking about creating and destroying lots of widgets during interactive operation.

Actually, you're not likely to see a problem until you get over a few hundreds of widgets (depending on your hardware setup). Still, it would be better to configure the GUI so that it has a constant size and complexity from the user's point of view regardless of data quantity, and so that its memory and execution load grow in very small increments as data quantity increases.

Consider a layout where you present the hash data in a Listbox, and allow the user to select any one Listbox item at a time, in order to edit the selected item -- this means you need only one Entry widget (or one set of Entry widgets, one for each editable "field" in the Listbox item), where the user can alter the content of the selected item. Once the user hits a "commit" button, the chosen entry is replaced in the Listbox (i.e. delete the old and insert the new at the same index).

Changing the contents of a Listbox is quick, easy, stable, and doesn't disrupt the user's view of the process. Changing the quantity of Entry widgets, even if these are in some sort of scrolling frame, is slower and more complicated.