Hello folks! I'm using the `concurrent.futures.ProcessPoolExecutor` with a couple of functions that have been decorated with a class decorator. Both `concurrent.futures` and `multiprocessing` breaks because "the object's can't be pickled". There's a really simple fix for this, which is just, instead of "decorating" the function (with the @), instantiate the decorator and use it directly. Example. This is my (very simple, for demonstration purposes) decorator: class CheckOnlyIntegers: def __init__(self, fn): self.fn = fn def __call__(self, *args): if not all([type(arg) == int for arg in args]): raise ValueError("Invalid param is not an integer") return self.fn(*args) If I define a simple `add` function and decorate it using the `CheckOnlyIntegers` decorator: @CheckOnlyIntegers def add(x, y): return x + y and try using a regular `ProcessPoolExecutor().submit(add, 2, 3)`, it fails with: ``` Can't pickle <function add at 0x10ace3e18>: it's not the same object as __main__.add. ``` The fix for this is simple, instead of "decorating" the function, instantiate the class and use a different name: def add(x, y): return x + y add_2 = CheckOnlyIntegers(add) In this case `ProcessPoolExecutor().submit(add_2, 2, 3)` works correctly. (here's the full sample code <https://gist.github.com/santiagobasulto/2bc51e7b0b0c7c2a74fd6d5748778dd7>) I know this is an issue with the pickle module (not concurrent.futures or multiprocessing). But are there any ways of improving this in future versions? Not being able to pickle functions decorated with Class Decorators seems like an unnecessary limitation. Thanks for your feedback! -- Santiago Basulto.- Up!