关于命名约定:Python args和kwargs在实践中是否曾被命名为其他东西?

Are Python args and kwargs ever named something else in practice?

python不限制参数的名称,但是有些参数名称受约定的严格控制,如selfclsargskwargs。名称selfcls总是代表相同的概念,因此在这些情况下,我很难看到有人背离惯例的一个令人信服的理由。然而,对于argskwargs,我发现这种命名约定令人窒息。

假设我有一个类,它具有各种属性,可以通过将Kwargs传递给它的构造函数来设置这些属性:

1
2
3
4
class MyObj:
    def __init__(self, **kwargs):
        for propname in kwargs:
            self.set_property(propname, kwargs[propname])

在这种情况下,Kwargs只用于作为该类实例的可设置属性,因此对我来说,编写如下定义是有意义的:

1
2
3
4
class MyObj:
    def __init__(self, **properties):
        for propname in properties:
            self.set_property(propname, properties[propname])

这样,只需查看方法的签名就可以了解Kwarg的用途。

一般来说,我认为传统是一件好事。然而,在我看来,总是使用argskwargs是一个错失的机会,无法向API用户传递有关函数/方法的args和kwargs的性质的有用信息。毕竟,它们是未命名或命名的参数的事实已经通过出现单个或两个星号清楚地表明了。

是否有人有在现实世界中,多开发人员代码中使用args和kwargs的替代名称的例子,或者在这些构造中使用其他变量名是否太过违反规则?

如果不使用这些传统名称真的是一个可怕的、可怕的想法,那么为什么会这样呢?


我看不出有任何理由反对使用上下文特定的名称,例如…

my_sum(*numbers)my_parser(*strings, **flags)等。

print文件称*objects文件。

zip文件称*iterables

itertools.chain在文档和docstring中使用*iterables

1
2
3
>>> from itertools import chain
>>> chain.__doc__.splitlines()[0]
'chain(*iterables) --> chain object'

collections.ChainMap在docs和__init__中使用*maps

1
2
3
4
>>> from collections import ChainMap
>>> from inspect import signature
>>> signature(ChainMap.__init__)
<Signature (self, *maps)>

请随意寻找更多的例子。