Multi-inheritance has nearly always bitten me later on, it can make unittesting, debugging, and sub-classing difficult, I suggest avoiding it with composition instead of inheritance whenever possible.  In either case since this subclass is basically empty, it's probably a sign it's not a useful extension point and could simply be added later if/when there becomes an actual need.

Also consider how these abstractions will be used in addition to possible extension/expansion (both should be easy): Because it's behaviour is tightly-coupled with the ``DockerCmdBase`` interface (i.e. taking a ``cmd`` and ``args`` list), it will be really abrasive to add the (likely) docker-daemon REST extension.  Meaning, the CLI-style ``cmd`` & ``args`` would require parsing that mirrors the real docker CLI - i.e. a pain in the butt.

Therefor, if you want the underlying behaviour to also be extensible, I'd suggest adding another abstraction-layer.  A layer that hides the low-level behavior details (i.e. CLI vs REST).  For example, this middle-layer could have generic methods like "run_container", "kill_container", etc.  A subclass can then easily be written to translate those calls into underlying ``AsyncDockerCmd`` calls or ``DockeDaemonREST`` calls - thereby hiding the behaviour details.

Does that make sense?