[Python-Dev] Unittest/doctest formatting differences in 2.7a1?

[Olemis Lang]

On Wed, Dec 9, 2009 at 12:45 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro <lregebro at jarn.com> wrote:
>>
>> > Evolving the tests to avoid depending on these sorts of implementation
>> > details is reasonable, IMO, and cuold even be considered a bugfix by
>> > the Zope community.
>>
>> Evolving doctest.py so it can handle this by itself would be
>> considered a bugfix by me. :)
>
> It's about time doctest got another run of development anyway.

+1 ... that's why I implemented `dutest` BTW (I wanted more out of doctest ;o)

> I can
> imagine a couple features that might help:
>
> * Already in there, but sometimes hard to enable, is ellipsis.  Can you
> already do this?
>
>     >>> throw_an_exception()
>     Traceback (most recent call last):
>         ...
>     DesiredException: ...
>

Probably useful ... unless /me want to match something inside the
error message (which seems very hard to specify if error messages
change from time to time )

> I'd like to see doctests be able to enable the ELLIPSIS option internally
> and globally (currently it can only be enabled outside the doctest, or for a
> single line).
>

Depending on what you mean when you mention «internally and globally»
, you could do such kinds of things with `dutest` too

> * Another option might be something version-specific, like:
>     >>> throw_an_exception() # +python<2.7
>     ... old exception ...
>     >>> throw_an_exception() # +python>=2.7
>     ... new exception ...

You mean skip LOCs if python version is not «compatible» with the one
specified in the doctests (e.g. # +python>=2.7) ?

> Maybe for instance "# py_version(less=2.7)"
>
[...]
>
> Or, maybe checkers could be extended so they could actually
> suppress the execution of code (avoiding throw_an_exception() from being
> called twice).

Ah ! Just what I thought !

IMO that choice should be made explicit in the test code but once
again doctest does not support something like

{{{
>>> if sys.version_info[:3] <= (2, 7) :
...           throw_an_exception()
 <old exception>
... else :
...           throw_an_exception() # +python>=2.7
...
 <new exception>
}}}

I'd definitely prefer something like that or like what you've
mentioned before (i.e. # +python<2.7)
but the idea needs to be refined ;o)

To be more explicit, the main limitation is that you cannot make
assertions for individual statements inside blocks (e.g. if, for ,
...) mainly because that's not how interactive sessions look like

;o)

> * Maybe slightly more general, would be the ability to extend OutputCheckers
> more easily than currently.

You can definitely play with these kind of things (e.g. change
OutputCheckers at runtime ;o) by using `dutest`  ;o)

> * Or, something more explicit than ELLIPSIS but able also be more flexible
> than currently possible, like:
>     >>> throw_an_exception()
>     Traceback (most recent call last):
>         ...
>     DesiredException: [[2.6 error message | 2.7 error message]]

IMO, this would be limited to be used only with tracebacks, and
ellipsis are more general than that (match against anything) My
preferences above.

PS: Sorry for the commercials . I'm just mentioning that there's
something out there that enhances doctest to support some features you
mentioned , that was proposed some time ago to be included in stdlib
[3]_ and (at least in theory) is waiting for assessment &| approval .
That time the main stopper was its recent release [1]_ , now it has
about (184 + 60 + 117 = 361 downloads from PyPI ;o) [2]_ ...

.. [3] [Python-Dev] An OO API for doctest / unittest integration...
        (http://mail.python.org/pipermail/python-dev/2008-August/081761.html)

.. [1] [Python-Dev] An OO API for doctest / unittest integration...
        (http://mail.python.org/pipermail/python-dev/2008-August/081762.html)

.. [2] Download dutest @ PyPI
        (http://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html