Logged In: YES 
user_id=44660

I do not entirely understand your questions, so I'll try to
describe the situation more clearly.

Imagine this code in foo.py:

  import doctest

  def do_something(x):
      """
         >>> do_something(3)
         4
      """
      if x == 0:
           return -1
      return x + 1

  if __name__ == '__main__':
      import doctest
      doctest.testmod()

Now run

  python -m trace --cover --missing --coverdir=output foo.py

trace.py will produce 'foo.cover' that looks like this

      1: import doctest

      1: def do_something(x):
             """
                >>> do_something(3)
                4
             """
      1:     if x == 0:
  >>>>>>          return -1
      1:     return x + 1

      1: if __name__ == '__main__':
      1:     import doctest
      1:     doctest.testmod()

It will also produce an empty file called '<doctest
__main__.cover', and produce a warning on stdout

  Not printing coverage data for '<doctest
__main__.do_something[0]>': [Errno 2] No such file or
directory: '<doctest __main__.do_something[0]>'

With my patch, trace.py will produce a 'foo.cover' file with
the same content, and it will not create empty files nor
produce any warnings.

(I do not particularly care about tracing Python statements
inside doctests themselves.  I would like to keep this bug
report focused, so if anyone wants doctest coverage in
addition to regular Python code coverage, I suggest opening
a new bug report.)

Given this, I think the answers to your questions are

  (1) yes

  (2) what is 'the code that creates a test'?  If you mean
the '>>> do_something(4)' line, then I'm content if it
remains untracked

  (3) whether doctests are in the same file or not is
irrelevant, in my opinion (in SchoolTool most of the
doctests are in separate files); I do not see where they
might get mistaken for code

  There are no test-portions-that-didn't run, so there's no
need for subdirectories.

  It would not be OK if some of the tests/doctests didn't
actually run because of trace.py.  Luckily, that is not the
case.