On Fri, Mar 2, 2012 at 11:14 AM, Guido van Rossum <guido@python.org> wrote:
On Fri, Mar 2, 2012 at 9:59 AM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
On Fri, Mar 2, 2012 at 12:30 PM, Guido van Rossum <guido@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/co...
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