Re: Invertible id(), or maybe hash the world, or ?

Steven D. Majewski (sdm7g@elvis.med.virginia.edu)
Wed, 6 Apr 1994 13:06:11 -0400

On Apr 4, 23:41, Jim Roskind wrote:
>
>
> The second time I hit this problem was in creating persistent objects.
> The problem was that I needed to save away the state of objects. I
> needed (wanted?) a way to remember the fact that I had already encoded
> an object in order to save time when asked to encode it again. It
> was actually more than a need, because I can handle recursively
> defined data. Hence when encoding data, which is a part of other
> lists etc., it is critical to identify the recursive requests.

[ ... ]

>
> It turned out that I needed to recover the actual object if I did hit
> a recursive problem, and this seemed about the only way to make it
> available (gracefully). If you don't know what I mean by the
> "recursive" problem, try executing the following three lines of code
> (which will crash python, as might be guessed by the warning in the
> reference manual):
>
> L = []
> L.append(L)
> `L`
>
> It really pays to remember what you are trying to represent ;-).
>

As will marshal.dumps( L )

Naievely copying and the codeobject case and modifying it for
funcobject in marshal.c

else if (is_funcobject(v)) {
funcobject *fn = (funcobject *) v;
w_byte(TYPE_CODE, p);
w_object(fn->func_code, p );
w_object(fn->func_globals, p );
w_object(fn->func_name, p );
}

Will also (usually) give you a nice infinite recursion on
marshal.dumps( function ), as it tries to dump function's
.func_globals dict, which in many cases contains other
function objects.

I know this for a fact. I *am* naive! :-)
But now I know that the the non inclusion of various types from
marshal was not an unintentional oversight!

- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics