Repository navigation
string.pickle makes some bad assumptions #61
Description
I wonder whether we should have a special metamethod for pickle? The assumption that tostring (object) will generate a string that can be passed to functional.eval doesn't even hold true for the objects we provide in stdlib.
Two options:
- Objects that can be pickled have a
__picklemetamethod (analogous to Python's__repr) that outputs a constructor for the object being pickled (including arequire "appropriate.module".constructor {args}rather than assuming"appropriate.module"is already loaded). - We have to be careful that
__tostringdoes double duty with the above.
I'm leaning heavily towards (1) because, among others, it makes a cannot pickle error easy to determine and produce.
Activity
gvvaughan commentedon Jun 7, 2014
I forgot to mention, that I wonder why
pickleisn't built withrender? That would at least solve the TODO item for handling recursive tables, although not in a way that promotes rebuilding the pickled object with functional.eval... so maybe I answered my own question?rrthomas commentedon Jun 7, 2014
I agree with leaning towards option 1. I suspect the reason
pickleisn't built onrenderis that it's supposed to be canonical, i.e. not customizable; of course, it assumes (at least in the original version I'm looking at) that tostring produces an eval-able representation, which only makes sense for primitive types.I have some concerns. I think we need to make sure that
pickleis supported where possible; whereas the temptation is to write a quick-and-dirtytostringmethod, and "worry about pickle if we need it". Can we give some incentive to do the opposite? What is it that makes pickles hard to digest, other than recursion, and suitable escaping of strings? Could we in fact end up with just pickling and pretty-printing, and implement the latter on top of the former, so that by default new classes only implement__pickle?gvvaughan commentedon Jun 8, 2014
That feels like a good approach, and should be quite easy to implement in the existing stdlib uses. I'll work on that then thanks :-)
Although object and container rely on
__totable, I can't shake the feeling that having__pickle,__tostringand__totableis unnecessarily baroque, so it would be really nice to find a way of teasing apart the requirements such that having to implement all three is a rare occurrence. Maybe I needn't worry if object and container base classes have good enough defaults that they don't need to be overridden every time they are subclassed.gvvaughan commentedon Jul 21, 2014
Clean ups to
__totablein #68 make the implementation ofstd.objectclearer and more idiomatic, and allows for simpler complex object creation where the default__pickleand__pairsmetamethods adequately service pickling, pretty-printing and cloning functionality without overrides in children 😀gvvaughan commentedon Sep 12, 2015
Bad assumptions are gone. But the API requires too much gymnastics between
__pickleand__tostringwhen creating new object prototypes... more work required.