Things like shared fixtures and mocking become *harder* (although by no means impossible) in a doctest environment.
This, I think, what I was suggesting with doctest "scoping" where the execution environment is a matter of how nested the docstring is in relation to the "python semantic environment", with a final scope of "globs" that can be passed into the test environment, for anything with global scope.
Another thing I dislike is that it encourages a "test last" approach, as by far the easiest way of generating doctests is to copy and paste from the interactive interpreter. The alternative is lots of annoying typing of '>>>' and '...', and as you're editing text and not code IDE support tends to be worse (although this is a tooling issue and not a problem with doctest itself).
This is where I think the idea of having a test() built-in, like help(), would really be nice. One could run test(myClass.mymethod) iterively while one codes, encouraging TDD and writing tests *along with* your code. My TDD sense says it couldn't get any better.
More fundamental-ish problems:
Putting debugging prints into a function can break a myriad of tests (because they're output based).
That's a good point. But then it's a fairly simple matter of adding the output device: 'print >> stderr, 'here I am'", another possibility, if TDD were to become more of part of the language, is a special debug exception: "raise Debug("Am at the test point, ", x)" Such special exceptions could be caught and ignored by doctest.
With multiple doctest blocks in a test file running an individual test can be difficult (impossible?).
This again solved with the test() built-in an making TDD something that is a feature of the language itself.