[Python-ideas] doctest

[Ian Bicking]

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

>
>
> On 27 February 2012 23:23, Mark Janssen <dreamingforward at gmail.com> wrote:
>
>> On Mon, Feb 27, 2012 at 3:59 PM, Michael Foord <fuzzyman at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120227/7332f159/attachment.html>