Decoupled chain of responsibility in Python
This looks unfinished to me and far from ready for review.


The docstring for the class Processable doesn't describe the class. What kind of thing is an instance of Processable?
The class Processable is misleadingly named — its instances are things that can process not things that can be processed so a name like Processor would be better.
The execute method has no docstring. What does it do?
The purpose of the execute method is surely to process a request, but in that case shouldn't it take the request as a parameter?
Why does the execute method return a string? This seems to be an unnecessary limitation: a processing chain might need to return a more complex object.
In the chain of responsibility pattern, a processor's default behaviour is to forward the request to the next processor in the chain. But this seems to be omitted from the implementation here. Where is the next processor stored? How is the request forwarded?
It is not clear what happens if none of the processors in the chain want to handle a request.
staticmethod is nearly always an anti-pattern in Python. In some languages (like Java) all functions have to belong to a class. But in Python you can just write a function, and there is no need to make a class whose only job is to act as a container for some functions.
There are no docstrings for process_directly and process_subclass. What do these functions do?
process_directly is coupled tightly to settings.CHAIN_PROCESSORS. It would be better for this to be a parameter, in case the application needs to construct its processor chain in some other way.
process_directly constructs a Processable instance and calls its execute method. But doesn't there need to be a request somewhere?
process_directly throws away the Processable instance after it is finished. This means that if you call it again it has to go through the construction logic again, which is a waste of time, and it makes it hard to implement stateful processors (because the objects don't survive from one execution to the next).
process_directly calls print on the result. It seems unlikely that this is what real processor chains will want to do with the result.
If the test issubclass(cls, Processable) fails, nothing happens. This means that typos and other mistakes in the setting will be silently ignored. It would be better to raise an exception.
I don't understand the purpose of process_subclass.
There's duplicated code (for loading a class from a module) between process_directly and process_subclass.