[Python-Dev] How to suppress instance dict? (original) (raw)

David Abrahams dave@boost-consulting.com
Sun, 23 Mar 2003 11:41:17 -0500

Guido van Rossum <guido@python.org> writes:

> I think you could subclass the metaclass, override new, and delete > the bogus getstate from the type's dict. Then you'll get the > default pickling behavior which ignores slots; that should work just > fine in your case. :-)

Ooh, that's sneaky! But I can't quite see how it works. The error message I quoted at the top about getstate happens when you try to pickle an instance of the class. If I delete getstate during new, it won't be there for pickle to find when I try to do the pickling. What will keep it from inducing the same error? Just try it. There are many ways to customize pickling, and if getstate doesn't exist, pickling is done differently.

Since this doesn't work:

>>> d = type('d', (object,), { '__slots__' : ['foo'] } )
>>> pickle.dumps(d())

I'm still baffled as to why this works:

>>> class mc(type):
...     def __new__(self, *args):
...             x = type.__new__(self, *args)
...             del args[2]['__getstate__']
...             return x
...
>>> c = mc('c', (object,), { '__slots__' : ['foo'], '__getstate__' : lambda self: tuple() } )
>>> pickle.dumps(c())
'ccopy_reg\n_reconstructor\np0\n(c__main__\nc\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n.'

especially since:

>>> dir(d) == dir(c)
1

I don't see the logic in the source for object.reduce(), so where is it? OK, I see it in typeobject.c. But now:

>>> c.__getstate__
<unbound method c.<lambda>>

OK, this seems to indicate that my attempt to remove getstate from the class dict was a failure. That explains why pickling c works, but not why you suggested that I remove getstate inside of new. Did you mean for me to do something different?

I note that c's slots aren't pickled at all, which I guess was the point of the getstate requirement:

>>> x = c()
>>> x.foo = 1
>>> pickle.dumps(x) == pickle.dumps(c())
1

Fortunately, in our case the slots are empty so it doesn't matter.

-- Dave Abrahams Boost Consulting www.boost-consulting.com