Refactor bigtools internals and API for writing #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…factor write_zoom_vals
…r. Cleanup docs and rename chsi vars to data.
…n new error that doesn't include SourceError
…Write over W: Write+Seek. Take chrom_sizes in create_file instead of write*.
|
Going to go ahead and merge this. Aside from the couple bug fixes, there should be no semantic differences or additions here (unlike the pybigtools refactor). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The adjustment here is the change to where iteration driven internally: rather than it being driven generically over the
ChromData, implementors ofChromDatadrive the processing themselves. This makes the internal logic much more clear and simple. It also makes the external API more clean too.It may be that there are future cleanups or changes that can be made here - one being allowing full external iteration (e.g. for pybigtools).
Performance-wise, this is essentially on-par or marginally faster than the existing implementation.