Move and update counting

[dheiman]

Pull Request Template

Squashing what is hopefully the last counting bug. This should fully resolve #21.

Style Checklist

Please ensure that your pull request meets the following standards for quality. Code should not be merged into the master branch until all of these criteria have been satisfied.

Comments

• [x] Each source file includes comments at the top describing its purpose
• [x] Each function includes a comment/docstring describing inputs and outputs, and any assumptions it makes
• [x] Variable and function names have semantic meaning, and are not reused with a different meaning within the same scope
• [x] “Magic” numbers, such index of a particular column name, have a comment describing their value, or are declared as a global constant with a semantic name (e.g. TCGA_ID_COL = 16)
• [x] Commented-out code is removed

Style/Execution

• [x] Code contains no hard-coded paths
• [x] Code contains appropriate logging & or debugging
• [x] If possible, input data is validated early in the execution. If not, errors are sufficiently detailed to aid debugging.
• [x] Code uses a library (e.g. optparse, argparse) for command-line parsing

[dheiman]

The final TODO for this branch is moving combined counting upstream from gdc_report.

[noblem]

Looks pretty nice! One question about approach: in lib/meta.py I liked the introduction of the named tuple, but in the tumor_code() method, why keep the code "as is" b/c it defines the data structure every time it's called? Why not define the structure once, outside the method, since it's invariant across the life of a tool's execution (and actually changes very little over time, in general)?

[dheiman]

I absolutely agree that the data structures should be defined outside of the function definitions - it's just something I planned to do en masse as a later code cleanup, as it occurs throughout the codebase.

On Fri, Mar 24, 2017 at 1:22 PM, noblem notifications@github.com wrote:

Looks pretty nice! One question about approach: in lib/meta.py I liked the introduction of the named tuple, but in the tumor_code() method, why keep the code "as is" b/c it defines the data structure every time it's called? Why not define the structure once, outside the method, since it's invariant across the life of a tool's execution (and actually changes very little over time, in general)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/broadinstitute/gdctools/pull/28#issuecomment-289087378, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLBxWk_p6NAh6qEmOuD7YvmemuTmEIUks5ro_vNgaJpZM4MoSS_ .

[noblem]

ok, make sense