testtools-dev team mailing list archive

["Martin \[gz\]" <gzlist@xxxxxxxxxxxxxx>]

> > The only behaviour change is str(MatchesException(Exception)) now returns
> "MatchesException(Exception)" rather than "MatchesException(<type
> 'exceptions.Exception'>)" which I think is nicer and makes life easier as
> across 2.4->2.5->3 you get three different reprs. Oh, and that exception
> classes custom repr methods now won't get used, which may be a good or bad
> thing for clarity, but should be safer at least.
> 
> I explicitly didn't do this because class names are not unique, and
> thats bad for debuggability.

Well, reprs aren't unique either, they're whatever gets returned from the __repr__ method. Is it socket.error etc. that you're concerned about? Would including the module name (if it's not "exceptions" or "builtins") work for you?

> We can special case exceptions.* types to show just the classname, if
> we want, but debuggability has to be waaaay up there in requirements.

The problem is there have just been a various changes in what that repr is, to enumerate:

Type:

<class exceptions.Exception at 0x00A74510>
<type 'exceptions.Exception'>
<class 'Exception'>

Instance:

<exceptions.Exception instance at 0x00C62A08>
Exception('fish',)

The actual Matcher str I'm not much worried about, but the Mismatch string I feel should be consistent across versions.

> Whats unsafe about what I'd done?

Nothing, that was just noting that `BaseException.__repr__(some_random_exception)` is less likely to blow up from buggy user code than `repr(some_random_exception)`.
-- 
https://code.launchpad.net/~gz/testtools/raises_regressions_675327/+merge/41342
Your team testtools developers is requested to review the proposed merge of lp:~gz/testtools/raises_regressions_675327 into lp:testtools.