>> Could this have been done with:  
>> setattr(self.__class__, "do_" + command, func)?

> Isn't that worse than doing that on an instance? It will work 
> as long as there's only one.

Why not have multiple classes instead of multiple instances?  Then use class composition to combine the components.

FWIW, I just looked through the Cmd2 project (which depends on and extends the Cmd class): https://cmd2.readthedocs.io/en/latest/index.html .  AFAICT, there is no precedent for the approach taken by your project.  This seems to be at odds with the design of module which is class based rather than instance based.

The existing class based design allows class composition which supports needs for separately maintained components.  It also allows regular methods to be dynamically attached to the class or any of its parents after the class is created.   Being regular methods, they would have access to the "self" instance parameter so that the application can be stateful (note that attaching functions to instances loses this advantage).  In Cmd2, the instance is considered the application and only one can be run at a time (it's not really about having multiple distinct instances that vary dynamically and independently of one another).

I've exhausted my triage efforts on this.  It doesn't seem be bug; rather, it is a feature request to take the module in a different direction that seems to be in conflict with its core concept and normal use (and in conflict with Python norms about where to attach methods).  

If you would like to push forward, consider eliciting opinions and analysis from Catherine Devlin and Todd Leonhardt (the maintainers of Cmd2).  If they think it is a good idea to have multiple instances with dynamically attached functions, then this feature request can go forward.