Translator API/misc improvements
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 重构
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- python
- 领域
- api, documentation
调研方向
首先审查 translator 模块、其抽象父类、实现类和 AlleleTranslator._create_allele，以及各个 from 方法。这是一份范围很广的愿望清单，因此请先确认预期的是文档、类型注解、fmt、kwargs 还是参数作用域方面的改进；在开始工作之前，必须为选定的项目定义 done。
由索引模型根据 Issue 内容生成。
描述
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
fmtvalues in an enum - Document
kwargsfor 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 withhelp()or in docs if we ever make them. - Not clear to me why args in
AlleleTranslator._create_alleleare kwargs -- if it's for flexibility between individual_from_fmtmethods, 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_fmtmethod, ...
- 主要语言
- Python
- 星标
- 64
- 派生
- 45
- 平均合并
- 4 天 4 小时
- 30 天内合并 PR
- 8
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ga4gh/vrs-python 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
ga4gh/vrs-python#540 · 8 条评论 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
ga4gh/vrs-python#673 ·
维护者通常 2 天内回复
-
Merge `vrs/2.1` into `v3`可能已有人在做 @korikuzma 于 6 天前认领。 未关闭v3
ga4gh/vrs-python#672 · 已指派 1 人 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 42/100
ga4gh/vrs-python#669 ·
维护者通常 2 天内回复
-
test(ci): dont make live network requests可能已有人在做 @theferrit32 于 20 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 45/100
ga4gh/vrs-python#659 · 1 条评论 · 1 个 reaction · 已指派 1 人 ·
维护者通常 2 天内回复
相似的 Issue
-
The changelog workflow excludes otelbot but not dependabot, so every Dependabot pull request fails the changelog check可能已有人在做 @ocelotl 今天认领。 未关闭
难度 1/5 1 小时以内 新手友好度 82/100
open-telemetry/opentelemetry-python#5825 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
cuga-project/cuga-agent#1020 ·
维护者通常 2 天内回复
-
难度 1/5 1 小时以内 新手友好度 70/100
microsoft/playwright#43640 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
stac-utils/stac-fastapi-elasticsearch-opensearch#965 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复