gwlilabmit / gwlilabmit/rendseq
store data in objects rather than arrays?
- Dominant language
- HTML
- Stars
- 0
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
So basically, I think it might make the interface a bit less janky if we had reads stored in an object with various attributes instead of a single array. The observation which really motivated me to consider this was the weird requirement we have to provide a chrom to write_wig. (ideally this information would just be collected during the call to `read_wig` in the first place, and then passed to `write_wig`, and the user wouldn't need to capture and pass this information....)
But one could imagine that there would be other benefits as well - for example calculating the z_scores/peaks/steps could now be done by adding a new attribute, or updating an attribute of reads.
Could also then build in an option to convert this data object into a `pd.DataFrame` object which could help downstream analysis. :)
Anyway - this is a potentially large refactor, so would love to hear if people had thoughts/suggestions/concerns before I embark :)
Contributor guide
Assessment
This issue has not been assessed yet.