Protect against bad contains/eq implementations in imported modules

[bitprophet]

Description

The classic-task test includes an expression, <object> in [list of Fabric API functions]. This explodes if <object> has a bad implementation of __eq__(), such as in psycopg2, whose STRING member is a type which attempts to force-cast to int in its __eq__(). The result is a very perplexing traceback claiming that one of the function objects we're testing against is an invalid literal for "int". (A simple example of this can be found here.)

I think a sensible defense against this would be to wrap that statement in try/except: ValueError, since most broken __eq__ implementations probably raise ValueError, and certainly this one -- a widespread module many Fabric users are likely to be using -- does. Would prefer not to do a blanket exception here as that could still mask other, fabfile or Fabric level bugs.

---

Originally submitted by Jeff Forcier (bitprophet) on 2011-07-27 at 05:44pm EDT

[kbd]

Here's a stack trace and test code for this issue: http://paste.pocoo.org/show/474750/

[bitprophet]

@kbd's reproduction of this problem seems to raise TypeError, not ValueError, which is a bit odd, but hopefully we can trap both without widening the "capturing real errors" net too much.

[bitprophet]

FWIW I got TypeError too when testing on Linux (where it was easier for me to install the real-world test case, psycopg2). I've set up the fix to check for both, and hopefully there are no "actually broken" __eq__ implementations that raise either of these exception classes, since this fix will swallow them.