Make the first steps towards detecting type errors for unary and binary operations.

In exceptions, one object was added for holding information about a possible
UnaryOp TypeError, object called `UnaryOperationError`. Even though the name
suggests it's an exception, it's actually not one. When inferring UnaryOps,
we use this special object to mark a possible TypeError,
object which can be interpreted by pylint in order to emit a new warning.
We are also exposing a new method for UnaryOps, called `type_errors`,
which returns a list of UnaryOperationsError.

1 files changed, 21 insertions, 0 deletions

diff --git a/astroid/exceptions.py b/astroid/exceptions.py
index 47f2fe50..1ac150d9 100644
--- a/astroid/exceptions.py
+++ b/astroid/exceptions.py
@@ -69,3 +69,24 @@ class NoDefault(AstroidError):
     no default value
     """
 
+
+class OperationError(object):
+    """Object which describes a TypeError occurred somewhere in the inference chain
+
+    This is not an exception, but a container object which holds the types and
+    the error which occurred.
+    """
+
+
+class UnaryOperationError(OperationError):
+    """Object which describes operational failures on UnaryOps."""
+
+    def __init__(self, operand, op, error):
+        self.operand = operand
+        self.op = op
+        self.error = error
+
+    def __str__(self):
+        operand_type = self.operand.pytype()
+        msg = "bad operand type for unary {}: {}"
+        return msg.format(self.op, operand_type)