ga4gh / ga4gh/vrs-python

Translator API/misc improvements

Open
#475 2 comments 1 reaction 0 assignees View on GitHub
enhancement VRS translator
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.