On 2006/05/05, at 22:49, Colin McMillen wrote:
Am I checking for equality in the wrong way? Or am I approaching the problem in the wrong way?
I'm not sure if this is the Right Way of doing things, but I got around this in my own application by making my Copyable objects have a unique ID. Keep your objects in a dict that maps from id -> object, and then just say something like:
objDict[obj.objID] = obj
whenever you get an object back. Possibly you want to check to see if the object is already in the dict, depending on your application-level constraints -- in my particular application, it would be considered an error to send back an object with an ID that wasn't already known by the server. (Also, you may or may not want to set __eq__, __lt__, etc. to compare these objects by their ID.)
Thanks Colin, this would actually work fine for what I need to do. I just figured that I was doing something wrong since it's mentioned in a few places that Twisted should be able to do this. Perhaps I am mistaking Copyable with Referenceable however... The example from the docs I was thinking of where an object is send on a round trip then compared using '==' is actually a pb.Referenceable (I think Copyable is a subclass though)?
Anyway, your solution should work and I might use that for the time being. All objects that could possibly go out to clients and come back again should be stored in the ZODB, so I might be able to use whatever ID it uses, or generate one myself otherwise.
If anyone knows the "Twisted Way" do deal with several clients sharing lists of objects (or even just complex objects that refer to other objects) please let me know.
Thanks all for the fast responses!
Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python