copy_reg.py class.__flags__ & _HEAPTYPE check in 2.2.1? Why?
Martin v. Loewis
martin at v.loewis.de
Thu Aug 8 09:36:36 CEST 2002
"Mike C. Fletcher" <mcfletch at rogers.com> writes:
> Okay, says I, but here's the thing, _why_ does copy_reg care about
> the _HEAPTYPE flag 1<<9 (which is from object.h, apparently) when
> doing pickling/copying? Is there some reason such objects can't be
For those objects, it depends on the base type whether or not they can
be pickled: if their non-Heaptype base can be pickled, they can also
be pickled. If you inherit from a non-picklable type, the subtype will
also be non-picklable.
Notice that this code really is object.__reduce__. A heaptype object
is pickled by producing a base value, and storing the base value and
the dictionary state of object. The base value is created by finding
the first non-heaptype base, and constructing an instance of the
basetype from the object-to-be-pickled. To reconstruct the original
value, a reference to copy_reg._reconstructor is also pickled.
> In my particular case, I'm looking at allowing pickling of objects to
> disk which are normally not picklable (sub-classes of ZODB4's
> Persistent class). I'm basically wondering what this machinery is
> there for, and if killing it off for a particular run of a program
> will precipitate the end of civilisation?
If you run into this code, then there is a good chance that killing
this machinery will result in a pickle that cannot be restored.
More information about the Python-list