[Python-ideas] Adding `Unpicklable` to the `collections` module

[Ram Rachum]

Antoine Pitrou <solipsis at ...> writes:

> 
> On Tue, 23 Nov 2010 22:46:51 +0200
> cool-RR <cool-rr at ...> wrote:
> > (Spelling note: People told me that "pickleable" (with an "e" in the middle)
> > makes more sense, so I'm using that now.)
> > 
> > The best solution might be to have both a `Pickleable` class and
> > an `Unpickleable` class. The reason to have the former is that
> > `isinstance(thing, Pickleable)` is more natural, and the reason to have the
> > latter is because we can't require people to inherit from `Pickleable` for
> > every single class that they define. (Since pickleability is the rule and
> > unpickleability is the exception.)
> > 
> > So `Pickleable` could have a `__subclasshook__` that would do the real work,
> > similarly to `Iterable`.
> 
> The problem is that "doing the real work" can be CPU-intensive, and I
> don't think we would like isinstance() calls to become arbitrarily
> expensive (even if technically it's possible).
> 
> An alternative is simply to catch the exception when trying to pickle a
> value. That implies that the type takes care to raise an exception if
> pickling would work but unpickling wouldn't, which is what file objects
> now do.
> 
> By the way, "Unpickleable" doesn't work since it's ambiguous: you don't
> know whether it means you can unpickle the thing, or you can't pickle
> it.
> 
> Regards
> 
> Antoine.


Sorry, I didn't explain well enough: I meant that only inherently unpickleable 
objects, like files and locks, will be instances of `Unpickleable`. So if we 
have a list containing a file or a lock, it will still be an instance of 
`Pickleable`, as well as an object which refers to a file/lock as an attribute.

Maybe this is a good case for having only the negative `Unpickleable` and not 
the positive `Pickleable`.


Ram.