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.)
<object> in [list of Fabric API functions]
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
Here's a stack trace and test code for this issue: http://paste.pocoo.org/show/474750/
@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.
Fix re #397
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.
Changelog entry re #397