A __reduce__ function handling **kwargs

[Nathann Cohen]

Hello everybody,

I have a simple problem. I need to implement a __reduce__ function for pickling,
and such a function must apparently return a pair:

(f, args)

You can then build the original object with "f(*args)".

I would like to do the same, but with additional "keywords arguments",
i.e. something like:

(f, args, kwargs)

Which would then be used as f(*args, **kwargs). It can work with an intermediate
function, but I would really like to avoid it. Especially since this problem
must have been solved 1000 times already.

Thaaaaaaaanks,

Nathann

[Jeroen Demeyer]

Something vaguely like that is possible using __getstate__ and
__setstate__, see http://trac.sagemath.org/ticket/18109

[Nathann Cohen]

> Something vaguely like that is possible using __getstate__ and __setstate__,
> see http://trac.sagemath.org/ticket/18109

Err.. Well, in my case the function I call is not the class'
constructor. Because of ... reasons :-P

I ended up writing an unpickle function, which is more or less
forwarding a dictionary to the constructor ;-)

Nathann

[Jeroen Demeyer]

On 2015-05-04 13:55, Nathann Cohen wrote:
>> Something vaguely like that is possible using __getstate__ and __setstate__,
>> see http://trac.sagemath.org/ticket/18109
>
> Err.. Well, in my case the function I call is not the class'
> constructor.

That doesn't matter.

> I ended up writing an unpickle function, which is more or less
> forwarding a dictionary to the constructor ;-)

I guess it would be simpler to use __setstate__() in your use case.

[Nathann Cohen]

Yo !

> I guess it would be simpler to use __setstate__() in your use case.

What is the difference between setstate and a helper function ? O_o

Nathann

[Jeroen Demeyer]

Not much, only that __setstate__() is a cleaner design and that
__getstate__() is easier to doctest than __reduce__().

[Nils Bruin]

You should probably view the initial creation (whether it's a class constructor or a helper function) as roughly equivalent to __new__ and treat __setstate__ as __init__, although the split is not quite equivalent.
In the pickling process these two phases need to be split (and get split in slightly different ways) because of circular references: they can only be introduced by __setstate__.
For safety against reference cycles, you should do most of your work during __setstate__, because reconstructing cycles might not give you an error during unpickling, but malformed objects instead. On the other hand, if your object might get used as a key during `__setstate__` in reference cycles, then it must be able to hash and compare before its __setstate__ executes.