Pickling slotted instances

Andrew McNamara andrewm at object-craft.com.au
Mon Sep 16 08:40:37 CEST 2002


>I don't know what issues Guido had in mind, but here are a few for
>consideration:
>
>1. How to determine all slots? It has been proposed that __slots__
>   should return a tuple that includes base slots as well;
>   alternatively, iterate over base types yourself. Alternatively,
>   return slots in __dict__.

How is this handled in an instance now? Does an instance have slots
for all it's direct slots as well as the slots defined by it's base
classes? If so, it should probably be serialised in exactly this manner?

This is probably the nub of the matter - I'll need to look into the
implementation to learn more.

>2. Should all slots be pickled unconditionally? You seem to expect
>   this, but Samuele Pedroni points out that, in Java, some slots can
>   be marked transient, to avoid pickling them.

That would be nice, but we already have this problem with traditional
classes (I would guess this is one of the more common reasons to code
your own __getstate__ machinery with traditional classes)?

>3. How to pickle slots? You are suggesting that the list of slot names
>   is included, but that appears to be redundant - if you know the type,
>   you also know what slots it has.

Very true (what happens if the class implementation is changed? Some sort
of signature, at least, might be required, I guess).

>4. How to pickle unset slots? If a type has a slot but the instance
>   has not assigned the slot, requesting the slot value raises an
>   AttributeError.

It would seem simple enough to include a "not set" token in the serial
stream.

>If you are in doubt that this is really as tricky as presented, I'd
>encourage you to come up with a patch. In the process of implementing
>the patch, you may either find that all issues have a straight-forward
>solution, or that there are really serious issues remaining.

"Put your code where your mouth is"... 8-)

I'm sort of surprised that slots were added without having all the
bases covered, but I'm presuming that they are really a manifestation
of the internal machinery that was added for class/type unification,
and have been exposed in the language itself so people can see if it's
a useful feature.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/




More information about the Python-list mailing list