在 Sphinx 中,有没有办法在声明参数的同时记录参数?
我更喜欢在声明参数的同一行记录每个参数(根据需要),以便应用 DRY
如果我有这样的代码:
def foo(
flab_nickers, # a series of under garments to process
has_polka_dots=False,
needs_pressing=False # Whether the list of garments should all be pressed
):
...
如何避免重复文档字符串中的参数并保留参数解释?
我想避免:
def foo(
flab_nickers, # a series of under garments to process
has_polka_dots=False,
needs_pressing=False # Whether the list of garments should all be pressed
):
'''Foo does whatever.
* flab_nickers - a series of under garments to process
* needs_pressing - Whether the list of garments should all be pressed.
[Default False.]
在 python 2.6 或 python 3 中通过某种装饰器操作可能实现这一点吗?还有其他办法吗?
I prefer to document each parameter (as needed) on the same line where I declare the parameter in order to apply D.R.Y.
If I have code like this:
def foo(
flab_nickers, # a series of under garments to process
has_polka_dots=False,
needs_pressing=False # Whether the list of garments should all be pressed
):
...
How can I avoid repeating the parameters in the doc string and retain the parameter explanations?
I want to avoid:
def foo(
flab_nickers, # a series of under garments to process
has_polka_dots=False,
needs_pressing=False # Whether the list of garments should all be pressed
):
'''Foo does whatever.
* flab_nickers - a series of under garments to process
* needs_pressing - Whether the list of garments should all be pressed.
[Default False.]
Is this possible in python 2.6 or python 3 with some sort of decorator manipulation? Is there some other way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我会这样做。
从这段代码开始。
我会编写一个解析器来获取函数参数定义并构建以下内容:
这是对各种参数字符串模式进行一些相当直接的正则表达式处理,以填充文档模板。
许多优秀的 Python IDE(例如 PyCharm)都理解默认的 Sphinx
param
表示法,甚至在 IDE 认为不符合声明类型的范围内标记变量/方法。注意代码中多余的逗号;这只是为了让事情保持一致。它没有坏处,而且可能会简化将来的事情。
您还可以尝试使用 Python 编译器获取解析树,对其进行修改并发出更新代码。我已经为其他语言(不是Python)做过这个,所以我对它有一点了解,但不知道它在Python中的支持程度如何。
而且,这是一次性转变。
函数定义中的原始内联注释并不真正遵循 DRY,因为它是一种非正式语言的注释,除了最复杂的工具之外,任何其他工具都无法使用它。
Sphinx 注释更接近 DRY,因为它们采用 RST 标记语言,这使得使用
docutils
中的普通文本解析工具更容易处理它们。只有工具可以利用它,它才是 DRY。
有用的链接:
https://pythonhosted.org/an_example_pypi_project/sphinx.html#function-definitions
http://sphinx-doc.org/domains.html#id1
I would do this.
Starting with this code.
I would write a parser that grabs the function parameter definitions and builds the following:
That's some pretty straight-forward regex processing of the various arguments string patterns to fill in the documentation template.
A lot of good Python IDEs (for example PyCharm) understand the default Sphinx
param
notation and even flag vars/methods in the scope that IDE thinks does not conform to the declared type.Note the extra comma in the code; that's just to make things consistent. It does no harm, and it might simplify things in the future.
You can also try and use the Python compiler to get a parse tree, revise it and emit the update code. I've done this for other languages (not Python), so I know a little bit about it, but don't know how well supported it is in Python.
Also, this is a one-time transformation.
The original in-line comments in the function definition don't really follow DRY because it's a comment, in an informal language, and unusable by any but the most sophisticated tools.
The Sphinx comments are closer to DRY because they're in the RST markup language, making them much easier to process using ordinary text-parsing tools in
docutils
.It's only DRY if tools can make use of it.
Useful links:
https://pythonhosted.org/an_example_pypi_project/sphinx.html#function-definitions
http://sphinx-doc.org/domains.html#id1
注释旨在部分解决 Python 3 中的此问题:
http://www.python。 org/dev/peps/pep-3107/
我不确定是否有任何工作将这些应用到 Sphinx 上。
Annotations are meant to partly address this problem in Python 3:
http://www.python.org/dev/peps/pep-3107/
I'm not sure if there has been any work in applying these to Sphinx yet.
如果没有预处理器,您就无法做到这一点,因为一旦编译了源代码,Python 就不存在注释了。为了避免重复,请删除注释并仅在文档字符串中记录参数,这是记录参数的标准方法。
You can't do that without a preprocessor, as comments don't exist for Python once the source has been compiled. To avoid repeating yourself, remove the comments and document the parameters only in the docstring, this is the standard way to document your arguments.