On Fri, Feb 17, 2012 at 9:23 PM, Ian Bicking <ianbicking@gmail.com> wrote:

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

...

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).

Yeah, I kinda agree, but in this case the doctests are always confined to the same module (or class) and have a standardized location, so always near at hand (at least if you're using them well) if you want to see what a variable used in a sub-test has been defined.

  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.

Yeah, doctests has these (globs and M.__test__), it's just that it takes you out of the mode of "executable documentation" and becomes less fun.

...

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.

Yes, but then this gets more into "my" idea of making a test() builtin, like help().  In that case, you could do fancy stuff where you wouldn't even have to test string output. Cheers, mark PS. Darn, I hate when I forget to reply-all...