doctests for interactive functions

Brian van den Broek broek at cc.umanitoba.ca
Fri Feb 9 19:50:58 EST 2007


Neil Cerutti said unto the world upon 02/09/2007 08:52 AM:
> On 2007-02-08, Brian van den Broek <broek at cc.umanitoba.ca> wrote:
>> Can I run the rough structure of my code past you to see if it
>> is in the vicinity of what you mean? (I have removed some
>> details for sake of a short(er :-)) post.)
> 
> Yes, this is a good way to think about it. Separate input from
> validation. The downside is that control flow grows warts.
> 
>> My .get method looks like:

<snip my code and description>

> Your scheme may run into trouble with unexpected end of file when
> input_function is not raw_input. File methods don't raise an
> exception for EOF, they just return "", the empty string. So you
> may need to check of that return value, and raise IOError for
> that case.
> 
>> ._process_invalid_input is implemented to provide useful

<snip more description>

>> Is this the sort of thing you mean, or is this the sort of
>> coupling you suggest I avoid?
> 
> It has to be coupled somewhere. This seems like a good place to
> do it. The private methods can all be tested individually, so the
> doctests for get can be quite simple, or even absent.
> 
> Note that sequestering the test input in a file doesn't allow for
> good examples, unfortunately.


Hi Neil and all,

It is unfortunate. It looks like either way, I'm stuck with a choice 
between runnable examples and realistic looking examples. I'll go for 
runnability, to ensure that the examples are up to date.

Your feedback on my design is much appreciated, Neil.

Best,

Brian vdB



More information about the Python-list mailing list