Bug 26362

twisted_telepathy.BaseTelepathyObject.__eq__ isn't right, and I'm not convinced it can be made right either.

Consider:

* channel C1 exists at object path /foo
* you make a proxy BaseChannel object P1 for it
* C1 closes
* C2 opens at object path /foo
* you make a proxy BaseChannel object P2 for it
* C1 is not C2 (they are separated chronologically) but P1 == P2 according to __eq__

This could be "fixed" by comparing P1.is_valid and P2.is_valid in __eq__, with telepathy-glib-like semantics. However, consider this:

* channel C1 exists at object path /foo
* you make a proxy BaseChannel object P1 for it
* C1 closes
* C2 opens at object path /foo
* you make a proxy BaseChannel object P2 for it
* P1 != P2 as desired
* C2 closes
* P1 == P2 (!)

Also consider:

* channel C1 exists at object path /foo in Gabble, which has unique name :1.42
* you make a proxy BaseChannel object P1 for (:1.42, /foo)
* you make a proxy BaseChannel object P2 for (o.fd.T.Connection.gabble.jabber.blah.blah, /foo)
* you make a proxy BaseChannel object P3 for (o.fd.T.ConnectionManager.gabble, /foo)
* P1, P2 and P3 are all the same channel, but compare unequal

The correct semantics for __eq__ *for channels* would be to compare (unique name, object path) tuples. This is not something a base class can, or should, know; the constructor for BaseChannel also doesn't necessarily get a unique bus name (in a synchronous way, at least).

To have a correct __eq__ method, you either need to delete it and use the default Python semantics (object equality, i.e. the "is" operator), or know specific details of each subclass and also restrict the constructor parameters.