[Twisted-Python] Why do I get a _Dereference instance?

[Patrik Blommaskog]

> Also, we have the peculiar case:
>
> 	def setCopyableState(self, state):
> 	    self.__dict__.update(state)
> 	    self.foo = state
>
> Which gives:
>
> 	{'pond': <twisted.persisted.crefutil._Dereference instance
> at 0x009B5ED8>,
> 'foo': {'pond': <cache_classes.SlaveDuckPond instance at 0x009AD808>},
> 'broker': <twisted.spread.pb.Broker instance at 0x009AD1B0>, 'luid': 2}
>
> So the item in 'foo' is dereferenced as expected, while
> __dict__["pond"] is
> not. Go figure!

Never mind this last one, I didn't think far enough there. While it works,
this is what I should have tried, and it doesn't work:

	def setCopyableState(self, state):
	    self.__dict__.update(state)
	    self.foo = state["pond"]


My guess, and I really should know better than to make guesses after
midnight, is that the dereferencing mechanism only works with the 'state'
dictionary itself. That is, in the post processing, it substitutes the real
object references for the _Dereference values in the 'state' dictionary for
the keys it knows. As long as I keep the original state dictionary as master
data, at least until the deserializing is done, everything will work as
expected.

Thinking a little more (still on the wrong side of midnight), I can't really
see a Pythonic way of how the dereferencing mechanism could be solved the
way I initially wanted, i.e. self.__dict__.update(state). I can only come up
with a solution where the _Dereference would have to work as a proxy, and I
guess that there could be some severe side effects.

Unless someone (on the right side of midnight) can suggest something or
point out the error in my thinking, I think I will have to redesign my data
strategy somewhat.


- Patrik