[Twisted-Python] Is there pb documentation somewhere?

[Glyph Lefkowitz]

On Aug 18, 2014, at 12:37 PM, Daniel Sank <sank.daniel at gmail.com> wrote:

> glyph,
> 
> > A "resource" - i.e. a Referenceable - is just a Python object in memory.
> 
> Indeed.
> 
> > but in normal operation, Python objects don't spontaneously ascend
> > to a different plane of existence - as long as there are pointers to them in
> > memory
> 
> Of course.
> 
> > in the case of Referenceables that are currently in use, a reference
> > from a dictionary on the Broker instance for the client which is using
> > them
> 
> Suppose I have a Thingy:
> 
> myThingy = Thingy()
> 
> I want to give you some amount of access to manipulate myThingy, so I make a Referenceable which has some connection to it:
> 
> myReferenceable.thingy = weakref.proxy(myThingy)
> 
> and I send you the Referenceable. Now suppose I do
> 
> del myThingy
> 
> Now myThingy will be garbage collected. Then, if you invoke methods on myReferenceable, they'll fail. Is this what we want, or should I tell you that your RemoteReference should be considered stale?
> 
> If I'm not thinking about this correctly please advise. I realize that I could have done
> 
> myReferenceable.thingy = myThingy
> 
> so that myThingy lives as long as myReferenceable, but this doesn't actually seem like what I would normally want.

Why would you not normally want that?

What you're saying here is that MyReferenceable requires a thingy in the 'thingy' attribute to do its job.  MyReferenceable is a Python class in your application - its clients will call its methods, and it should take care that its methods do something sensible.  The fact that its clients are remote via the Broker class is almost irrelevant.

If you pass a type MyReferenceable doesn't expect - a weakref.proxy that suddenly becomes invalid when the inner object goes away - you'll get nonsense behavior.  But this isn't specific to Referenceable or remote access - if you just had an A and a B, and A expects a 'b' attribute that's a B, and you set 'b' to something that isn't a B, you get the same kind of nonsense behavior. 

(Also, if you require a 'thingy' attribute it should probably be a constructor argument rather than an externally-set attribute, so that the instance is initially in a valid state.)

-glyph