[Python-ideas] doctest
Mark Janssen
dreamingforward at gmail.com
Sat Mar 3 03:26:29 CET 2012
On Fri, Mar 2, 2012 at 11:14 AM, Guido van Rossum <guido at python.org> wrote:
> On Fri, Mar 2, 2012 at 9:59 AM, Devin Jeanpierre <jeanpierreda at gmail.com>
> wrote:
> > On Fri, Mar 2, 2012 at 12:30 PM, Guido van Rossum <guido at python.org>
> wrote:> Was there something else I was supposed to write, other than the
> > solution I advocated? ;)
> >
> >
> https://bitbucket.org/devin.jeanpierre/doctest2/src/e084a682ccbc/doctest2/constants.py#cl-122
>
> It's not a solution. It's a hack that only works in the simplest cases
>
With all respect to Guido, who has mentioned probably the best solution so
far (using sys.displayhook()) , on Devin's behalf, I must say that for
those of us dedicated to TDD using doctest, we tend to be writing code in
tandem to an ideal that doctest engenders; generally speaking: everything
being written is so fine grained, that the problems that most people are
speaking of, never arise. E. g., the tests are small and uncomplicated
because they are written right to the core of the source, there is
semi-rigid protocol for __repr__ in line with being eval'able, and code is
broken apart so that when the tests gets too complicated, it's a sign that
the code is not modular or fine-grained enough.
Just as the way OOP eventually evolved into the ideal of the "abstract base
class" as a way to match the notion of physical objects with programmatic
ones. Python + doctest approach a different apex, catching two birds with
one stone: documentation + TDD.
Just my small input...
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120302/ea4b4a95/attachment.html>
More information about the Python-ideas
mailing list