You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, thanks for the reproducer. The reason is some bad interaction between wrapt and cloudpickle. cloudpickle usually pickles all methods of a dynamically defined class, including __call__ and __init__ .
is severely confusing cloudpickle, and makes cloudpickle treat prepare_data as a function, whereas it should treat is as a instance of FunctionWrapper.
I'm not sure whether there is a path forward yet. I believe wrapt could at least include some __reduce__ method for such objects, but such an isinstance logic will still create a false positive during the reducer_override callback invocation of cloudpickle, which looks for function objects that are pickled in a custom manner prior to relying on __reduce__-based pickling logic for the object in question. So ideally, wrapt would reconsider their instance checking semantics...
Overwriting the logic inside
__call__
method of the wrapper:Running the decorated function works as expected (num of rows printed):
Once it is cloudpickled and loaded,
__call__
gets lost (num of rows is not printed)Same happens for the
__init__
. Any suggestion for keeping those functions with cloudpickle?The text was updated successfully, but these errors were encountered: