Are non-reified docstrings acceptable? #1734
|
Unlike modules, classes, and functions/methods, variables/constants do not technically support docstrings. However, it is fairly common to write what is conceptually a docstring immediately after an assignment statement, as an expression statement consisting of a triple-quoted string, with no blank line in between. This is recognized by some editors, including VS Code, as a docstring, and helpfully displayed when one hovers over or otherwise examines information on the variable/constant it documents. Of course, calling I think it would be useful to convert some comments atop variable/constant assignment statements to this kind of "docstring", and perhaps to add them for some variables/constants that currently are not directly documented. But I wanted to check, since it may be that for this project only true docstrings are preferred. As an example of this, here's one change that could be made in (Ordinarily I might just open a PR, which could be merged or not. But exactly where I'd add these depends on decisions related to other PRs: at least #1732, and possibly also a forthcoming PR that builds on #1729. So I figured I'd post this question instead.) |
Replies: 1 comment
|
Thanks for bringing this up! I think GitPython should try to provide a decent in-editor experience, and this seems to be improved by turning these comments on constants into non-reified docstrings. This would also be a guiding principle - there are no rules except for "don't break anyone" and "don't make it worse more than you make it better" :). |
Thanks for bringing this up!
I think GitPython should try to provide a decent in-editor experience, and this seems to be improved by turning these comments on constants into non-reified docstrings. This would also be a guiding principle - there are no rules except for "don't break anyone" and "don't make it worse more than you make it better" :).