Why DocTest?

Today (Thursday, August 03 2006) I had a conversation in #bzr channel like this:

(16:54:52) baijum: mpool: if we use an approach like this doctests will not be convoluted much,
(16:56:41) mpool: baijum: question is, why do you want to write doctests, rather than regular code?
(16:57:16) madduck: mpool: documentation and unit tests really go hand in hand so many times.
(16:57:47) madduck: before i learnt about TDD, i always shipped out example code, which would also 
           serve as a test script for me.
(16:58:07) madduck: that is, i always included all the functionality in the example code, 
           would refer people to it, but would also use it to test thigns
(16:58:18) madduck: i guess that sort of behaviour is\ where doctests came from
(16:58:46) mpool: i think they're useful in that case
(16:59:00) mpool: my point is just that not all tests make good examples, and vice versa
(16:59:11) madduck: i think if you are starting something new and you author for doctests, it works
(16:59:21) madduck: it's not always easy or even possible to add doctests later.
(16:59:32) mpool: e.g. the documentation for a function might have just one or two examples showing 
           typical use, but it might have a dozen tests
(16:59:36) madduck: right, the buildpackage bzr plugin will not really be a doctests candidate
(16:59:40) madduck: as it does filesystem stuff...
(16:59:46) mpool: yeah, that kind of thing
(17:00:09) mpool: i have a todo to sometime extend doctest to run shell commands from the bzr manual
(17:02:09) baijum: Then I think a better approach will be to split doctests to different files, one 
           for general usage patterns and other files with more test cases

Now I want to convince myself, why I prefer/like doctest over other methods.