On Mon, Feb 27, 2012 at 5:31 PM, Michael Foord <fuzzyman@gmail.com> wrote:


On 27 February 2012 23:23, Mark Janssen <dreamingforward@gmail.com> wrote:
On Mon, Feb 27, 2012 at 3:59 PM, Michael Foord <fuzzyman@gmail.com> wrote:
As well as fundamental problems, the particular implementation of doctest suffers from these potentially resolvable problems:
 
Execution of an individual testing section continues after a failure. So a single failure results in the *reporting* of potentially many failures.

Hmm, perhaps I don't understand you.  doctest reports how many failures occur, without blocking on any single failure.


Right. But you  typically group a bunch of actions into a single "test". If a doctest fails in an early action then every line after that will probably fail - a single test failure will cause multiple *reported* failures.
 
 
The problem of being dependent on order of unorderable types (actually very difficult to solve).

Well, a crude solution is just to lift any output text that denotes an non-ordered type and pass it through an "eval" operation.


Not a general solution - not all reprs are reversible (in fact very few are as a proportion of all objects).

Just an implementation suggestion - Guido's suggestion of using sys.displayhook will work to change the repr of objects (I had never heard of it until then, and had to test to convince myself).  Doctest needs reliable repr's more than reversable repr's, and you can create them using that.  You'll still get a lot of <foobar.Foobar object at 0x391a9df> strings, which suck... but if you are committed to doctest then maybe better to provide good __repr__ methods on your custom objects!  For doctest.js (where I implemented a number of changes I would have wanted for doctest in Python) I have found this sort of thing sufficient, but Javascript objects tend to be a little more bare and there aren't existing conventions for repr/print/etc, so I have some more flexibility in my implementation.

  Ian