WIP: list of contexts instead of None

#120 Declined
  1. Loic Dachary
No description

Comments (5)

  1. Loic Dachary author

    @ned while hacking on wtw I realized things could be easier if each arc/line was associated to a list of contexts. This pull request is an illustration of what I mean. Did you consider this approach ? If so, what made you prefer having one data set per context instead ?

  2. Loic Dachary author

    Updated with a draft adding the list of context that ran tests for the lines missing coverage (if they are a branch) or the closest line that got tested if not.

  3. Ned Batchelder repo owner

    I'll need to think about switching to a list of contexts. Off the top of my head, this new way will involve more operations in the trace function. We need to do everything we can to make the trace function fast.

    You've put code into pytracer.py: that code needs to be as slim as possible, and won't have support for wtw. It's OK for prototyping, but keep in mind that only the C tracer can afford to have logic about wtw in it.

  4. Loic Dachary author

    @ned having a list of contexts means that instead of = None we have .add(self.context) which is slower and consumes more memory. This is not good :-)

    The hack modifies the output of the summary like so:

    Name    Stmts   Miss Branch BrPart  Cover   Missing
    a.py        7      1      2      1    78%   5, 4->5
      4 /home/loic/software/coveragepy/issue-170/reproducer/a.py:tests
      5 /home/loic/software/coveragepy/issue-170/reproducer/a.py:tests
    c.py        2      0      0      0   100%
    TOTAL       9      1      2      1    82%

    While implementing it I realized that if the data was segregated in different contexts it needs to be saved in a different file after run, then have to be merged back together during the report phase. I felt the code to do that was a bit too complicated for prototyping and tried hacking the .coverage file format instead. This is also why I chose to modify pytracer instead of ctracer: it's easier.

    This approach has a number of performance problems, as you pointed out. To the extent that it will need to be completely re-implemented before it can be released.This is however worth pursuing at this stage because we're trying to find at least one use case that deserves a proper implementation. If the hack is simple, trying variations and alternate use cases will be easier.

  5. Loic Dachary author

    I merged master into this branch and had to hg push --force because it created a new head. The bitbucket interface (below) then offers to update the pull request. But fails when it finds that the source branch has multiple heads.


    Unless someone knows of a way to update this pull request, I'll open a new one to continue the discussion with more code.