Example here.

Is this a callback from outside the sphere?

Perhaps this is actually a different kind of callback, then?

Bringing up the ColorPicker blocks, is hard to interrupt, and will prevent a program from exiting naturally by "falling off the end".

This is no "bug" - it is intrinsic to a lot of GUIs in Python.

Like so many other C based programs, matplotlib has to run on the main thread, but that means it interacts badly with other Python programs, and control-C.

There is a nice solution.

You start a new multiprocessing.Process which communicate to the original process with a pair of queues. So the new process has matplotlib on its main thread, and you are free to continue.

Blocking on a multiprocessing.Queue until it becomes non-empty is very cheap.

To shut down, you put a None onto the queues and the receiving process reads those and sends a Quit command to matplotlib.

"Customization points" are the places that an end user can set values to change the behavior of the colorsphere.

Because of the dependency on matplotlib, this package can only use Python 3.7 and above. This is good news!, because we can use dataclasses, which are a great way to implement and document an API at the same time.

You can see I sketched out a single class here, but it's glued together with the callback handler. In the final state, there would be an almost pure dataclass with all the user settings in it, and the callback handler would simply contain that dataclass and nothing else.

The same problem exists with the original code, but here's a demo with slightly newer code.

If from_shell=True, everything works fine. If from_shell=False, then you can see another application is started, and then you see the numbers from 0 to 19 printed, but you do not see the colorsphere.

Moving these two lines out of the if statement makes no apparent difference.