Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork938
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 madein -# Mapping of expected failures for the test_cygpath_ok test. _cygpath_ok_xfails = { # From _norm_cygpath_pairs: (R"C:\Users", "/cygdrive/c/Users"): "/proc/cygdrive/c/Users", (R"C:\d/e", "/cygdrive/c/d/e"): "/proc/cygdrive/c/d/e", ("C:\\", "/cygdrive/c/"): "/proc/cygdrive/c/", (R"\\server\BAR/", "//server/BAR/"): "//server/BAR", (R"D:/Apps", "/cygdrive/d/Apps"): "/proc/cygdrive/d/Apps", (R"D:/Apps\fOO", "/cygdrive/d/Apps/fOO"): "/proc/cygdrive/d/Apps/fOO", (R"D:\Apps/123", "/cygdrive/d/Apps/123"): "/proc/cygdrive/d/Apps/123", # From _unc_cygpath_pairs: (R"\\?\a:\com", "/cygdrive/a/com"): "/proc/cygdrive/a/com", (R"\\?\a:/com", "/cygdrive/a/com"): "/proc/cygdrive/a/com", }+"""Mapping of expected failures for the test_cygpath_ok test.""" (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.) |
BetaWas this translation helpful?Give feedback.
All reactions
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" :).
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" :). |
BetaWas this translation helpful?Give feedback.