[Python-Dev] Patching builtin_id to allow for C proxy objects?

Tom Whittock tom.whittock at gmail.com
Mon Jun 27 16:05:37 CEST 2011


Hi again.

Just to let you know that Greg's suggestion worked beautifully - I
guess my id idea was just me trying to make life hard for myself.

My concerns over the json modules usage of id seem unjustified, as
circular references are detected now that the weak reference
dictionary is in place.

Thanks for your help, and sorry for bothering dev with something which
was a regular python programming issue after all.

Tom.

On 27 June 2011 13:31, Tom Whittock <tom.whittock at gmail.com> wrote:
> Hi Greg thanks for your quick reply.
>
>> Perhaps you could use a WeakValueDictionary to keep a mapping
>> from a C++ object address to its Python proxy.
>
> Thank you, I'll implement this and see whether it works out. I'll
> certainly be better off if it does. I was avoiding holding weak
> references due to perhaps unfounded concerns about increasing the
> lifetime and speed/memory impact of certain temporary objects which
> are created at very high frequency. I'll test it and see before diving
> into messing with id. But now I'm thinking about it again, I can see a
> plan for not needing to affect that pathway at all.
>
> Seems I fell into the trap of making things too complicated for myself.
>
>> It also won't solve the problem of keeping the id of the
>> proxy for longer than the proxy exists, but that's probably
>> not something you should be relying on anyway. The id of
>> *any* Python object is only valid while the object lives,
>> and if it's still alive you have a real reference somewhere
>> that you can use instead of the id for identity testing.
>
> Thanks, yes. I'm actually kind of concerned about the usage of id in
> the markers set which the json library uses for circular referencing
> checks for exactly this reason. It seems to assume that the objects
> lifetime lasts for the duration of the encoding operation. I have no
> idea if that's actually the case in my situation, where data members
> are property getters producing probably very short lived proxies
> generated from C++. I guess I'll find out :)
>
> Thanks again,
> Tom.
>


More information about the Python-Dev mailing list