Translator API/misc improvements
- Dominant language
- Python
- Stars
- 62
- Forks
- 42
- Avg merge
- 1h 2m
- Merged PRs (30d)
- 1
Description
A wishlist/brainstorm:
- [ ] Richer documentation and type annotation. This module is serving a lot of roles right now and some internal design decisions have been made out of necessity for fulfilling those roles, and as personnel come and go/the years go on and on, we might lose sight of why those decisions were made. Stronger documentation about the *why* of some of these choices would help prevent breakage down the road (and might also resolve some of my thoughts/concerns below). Type annotation should be easier and would be a good short term step.
- [ ] Constrain global `fmt` values in an enum
- [ ] Document `kwargs` for translator methods directly in the implementation classes. Currently they're all located within the abstract parent, which means that docs for each implementation e.g. show the user some irrelevant kwargs.
- [ ] Make documentation for individual `_from_` methods accessible. Right now there's a docstring that refers a user to look at them for more information, but they're private (leading underscore), so the user technically isn't supposed to be able to/can't easily find them, either with `help()` or in docs if we ever make them.
- [ ] Not clear to me why args in `AlleleTranslator._create_allele` are kwargs -- if it's for flexibility between individual `_from_fmt` methods, there are a few ways we could make valid args more explicit, either naming them all and giving them defaults, doing fmt-specific post-processing within the `_from_fmt` method, ...
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.