The runnable example in the attached file, issue_23513_play.py, suggests a way to preserve the inheritance of the Result class in any subclasses of Thing yet leaves the definition of Thing.worker as the OP first had it (in the most straightforward way).

In creating other processes, the authors of multiprocessing needed a way to communicate objects from one process to another and the choice of pickle for serialization does require us to adjust our thinking a little but it does not mean we have to lose being pythonic.  Independent of whether multiprocessing is involved or not, returning a Result object from an instancemethod of another class might work without the definition of the Result class being in the current namespace, but it feels like a much more comprehensive solution to have the Result class available in the current namespace.  The attached proposes defining the Result class outside of the Thing class yet then adding it as a class attribute of Thing -- this gives both inheritability (which was missing in the "simple example") and visibility for pickling.  The convenience of a function like wrap_worker is just one tool that helps pickle figure out how to do its job -- this is part of a larger discussion around pickle and how to gracefully deal with non-trivial situations.

The attached is not being proposed as a final solution but does it help with your situation in particular?  Do parts of it look useful?