Hello Mr. Coles,
Sorry, but I fail to see the link between your question and the current thread. I guess you would have a better chance creating a new thread for your new question.
While I can't vouch for the reasoning behind this logic, I guess the main usage of a module using deap will be to perform evolutionary algorithms. If you need to import this module, don't use "from my_module import *" but specify the names of the objects you want to import. This is common practice to prevent the cluttering of your namespace. With that in mind, deap's globals won't pollute the rest of your applications. On a more technical point of view, putting the primitive set in the global variables of the module is quite handy. It prevents the need to pass references everywhere and also simplifies the use of parallel modules such as multiprocessing. Since the primitive set is already available from the global scope, there is no problem to initialize the rest of the program on a single worker and perform evaluations on multiple threads (which need the primitives to compile the individuals).
Have you got an example where this behavior is problematic?