I take 'fun' to mean you will try something.  And yes, I have thought about the following for all IDLE modules.

6. Replace "from tkinter import *".  It was mainly intended for interactive use. In production IDLE, use either
a. from tkinter  import Tk, Frame, Label, Button, <constants>
b. import tkinter as tk

6a requires more typing in the import statement, but as a replacement, leaves the rest of the code alone.  It documents what widgets will be used in the module.  It allows individual classes to be mocked for a particular test or group of tests.  I know I have done this for the tkinter TypeVar classes.

6b has a short import but requires more typing in the module body, especially when tkinter constants are present, as they are here.

When exploring or writing short, one-off programs, I usually use 'as tk'.  But for IDLE, I may have converted at least one file to 'as tk', but I am now using 'import Tk, ...' and prefer it.

My current thoughts about Tkinter constants versus string literals, such as BOTH versus 'both': The two forms by themselves are about equally easy to type.  The CAPS form is shorter but louder, whereas to me they are minor items that should not be loud. The constants seem designed to work with 'import *'; one can then potentially use name completion for the longer names.  After 'as tk', I think "tk.Both" is worse than "'both'".  For new code with explicit imports, adding constants to the imports is extra work.  For existing code with many constants, such as help_about, adding constants to the imports is less work than converting.  So I am inclined to leave them as are until such time as we might do a search-replace throughout idlelib.

When there are a few constants, I have put them after the classes.  For this module, I would like to try a separate import rather than use '\' line continuation.

from tkinter import TOP, BOTTOM, SIDE, SUNKEN, EW, ...
---

In one file with just two constants, I initially converted to the quoted literal, but another core dev objected on the basis that the constants are checked when the function is compiled instead of when called, and that this is somehow safer.  For when issue comes up again, I am recording my current replies here.

1. The same logic would suggest that we should write, for instance, "open(filename, mode=W, encoding=ASCII, errors=STRICT)" (after appropriate imports) instead of the current "open(filename, mode='w', encoding='ascii', errors='strict')".

2. If running a file to do a test compile also does a test call of create-widget functions, then the objection does not apply.  For every IDLE file that creates tk windows, there is an htest, initiated by running the file, that creates an instance of the window.  The first purpose is to insure that widget creation calls are legitimate.  The unit tests will eventually do the same, as in 1b above.  (The second purpose, not duplicated by unittests, is to see if the result 'looks good'.)