Raymond> Grep could find most potential changes but I don't see how you Raymond> can statically determine whether 'raise x' is a class or Raymond> instance without running the code. I agree no perfect solution is possible, but I think a 90% solution is easily acheived. If what's being raised is one of the standard errors and it's not mentioned as the lhs of an assignment within the module, it's almost certain that a standard exception class is being raised. That reduces the bulk of the problem down to reviewing the automatic changes. No matter how completely you try to automate the process, any converter or raise statement locator (like "egrep -n '^[\t ]*raise ' *.py") should print lines it modifies or discovers in a form which editors like Emacs can parse, e.g.: httplib.py:247: raise BadStatusLine(line) httplib.py:257: raise BadStatusLine(line) httplib.py:259: raise BadStatusLine(line) httplib.py:289: raise UnknownProtocol(version) httplib.py:475: raise IncompleteRead(s) httplib.py:482: raise ResponseNotReady() httplib.py:515: raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) httplib.py:545: raise socket.error, msg httplib.py:563: raise NotConnected() httplib.py:630: raise CannotSendRequest() httplib.py:697: raise CannotSendHeader() httplib.py:708: raise CannotSendHeader() httplib.py:767: raise ResponseNotReady() httplib.py:915: raise error(9, 'Bad file descriptor') httplib.py:928: raise UnimplementedFileMode() This makes it a lot easier to work your way through the lines which need attention. (Before people accuse me of being an Emacs bigot I readily admit that I am. Let me suggest that this magic tool take an optional format parameter which defaults to something like "%(file)s:%(line)d:%(source)s". That should allow the tool to format its output to most any text editor or ide's notions of what compiler error messages look like.) Skip