On Fri, Feb 17, 2012 at 8:25 PM, Ian Bicking <ianb@colorstudy.com> wrote:

On Feb 17, 2012 3:58 PM, "Mark Janssen" <dreamingforward@gmail.com> wrote:

...

I find myself wanting to use doctest for some test-driven development, and find myself slightly frustrated and wonder if others would be interested in seeing the following additional functionality in doctest:

1. Execution context determined by outer-scope doctest defintions 2. Smart Comparisons that will detect output of a non-ordered type (dict/set), lift and recast it and do a real comparison.

Without #1, "literate testing" becomes awash with re-defining re-used variables which, generally, also detracts from exact purpose of the test -- this creates testdoc noise and the docs become less useful.

I dunno... I find the discipline of defining your prerequesites to be a helpful feature of doctest (I find TestCase.setUp to be smelly).  You can include a namespace in doctest invocations, but I'm guessing the problem is that you aren't able to give these settings when using some kind of test collector/runner?  More flexible ways of defining doctest options (e.g., ELLIPSIS) would be helpful.

...

Without #2, "readable docs" nicely co-aligning with "testable docs" tends towards divergence.

IMHO this could be more easily solved by replacing the standard repr with one that is more predictable.  At least that would handle dictionaries, it becomes a bit more difficult for custom types.  Also it diverges from being exactly like the console, but eh, I don't think that's a big advantage.

Unfortunately plugging in a custom repr is kind of hard; Python has a way to specifically compile expressions into "print repr(expr)" (more or less) but no general way to get the value of expressions (while also handling statements).  But if you wanted to try it, I did figure out a terrible hack for it.

Isn't sys.displayhook() usable for this purpose? -- --Guido van Rossum (python.org/~guido)

On Fri, Feb 17, 2012 at 8:25 PM, Ian Bicking <ianb@colorstudy.com> wrote:

On Feb 17, 2012 3:58 PM, "Mark Janssen" <dreamingforward@gmail.com> wrote:

...

I find myself wanting to use doctest for some test-driven development, and find myself slightly frustrated and wonder if others would be interested in seeing the following additional functionality in doctest:

1. Execution context determined by outer-scope doctest defintions 2. Smart Comparisons that will detect output of a non-ordered type (dict/set), lift and recast it and do a real comparison.

Without #1, "literate testing" becomes awash with re-defining re-used variables which, generally, also detracts from exact purpose of the test -- this creates testdoc noise and the docs become less useful.

I dunno... I find the discipline of defining your prerequesites to be a helpful feature of doctest (I find TestCase.setUp to be smelly).  You can include a namespace in doctest invocations, but I'm guessing the problem is that you aren't able to give these settings when using some kind of test collector/runner?  More flexible ways of defining doctest options (e.g., ELLIPSIS) would be helpful.

...

Without #2, "readable docs" nicely co-aligning with "testable docs" tends towards divergence.

IMHO this could be more easily solved by replacing the standard repr with one that is more predictable.  At least that would handle dictionaries, it becomes a bit more difficult for custom types.  Also it diverges from being exactly like the console, but eh, I don't think that's a big advantage.

Unfortunately plugging in a custom repr is kind of hard; Python has a way to specifically compile expressions into "print repr(expr)" (more or less) but no general way to get the value of expressions (while also handling statements).  But if you wanted to try it, I did figure out a terrible hack for it.

Isn't sys.displayhook() usable for this purpose? -- --Guido van Rossum (python.org/~guido)