blocks|key|330398|text|如果您事先不知道参数的名称，那么**kwargs是很好的。例如，dict构造函数使用它们来初始化新字典的键。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|330399|kwargs+dict(**+|330400|+)+->使用关键字参数列表中的name=value对初始化的新字典。例如:+dict(one=1，two=2)|blockquote|330401|330402|330403|In+[3]:+dict(one=1,+two=2)
Out[3]:+{'one':+1,+'two':+2}|code-block|syntax|javascript|330404|entityMap^0|G|8|W|4|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|Z|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|10|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|12|8|@]|D|@]|E|$P|Q]]|$1|R|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|S|$]]

<code>**kwargs</code> are good if you don't know in advance the name of the parameters. For example the <code>dict</code> constructor uses them to initialize the keys of the new dictionary. 

<blockquote>
<pre><code>dict(**kwargs) -&gt; new dictionary initialized with the name=value pairs
 in the keyword argument list. For example: dict(one=1, two=2)
</code></pre>
</blockquote>

<pre><code>In [3]: dict(one=1, two=2)
Out[3]: {'one': 1, 'two': 2}
</code></pre>

blocks|key|3303218|text|真实世界的例子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3303219|装饰符-它们通常是通用的，所以你不能预先指定参数：|3303220|def+decorator(old):
++++def+new(*args,+**kwargs):
++++++++#+...
++++++++return+old(*args,+**kwargs)
++++return+new|code-block|syntax|javascript|3303221|你想用未知数量的关键字参数施展魔法的地方。Django的ORM做到了这一点，例如：|3303222|Model.objects.filter(foo__lt+=+4,+bar__iexact+=+'bar')|3303223|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Real-world examples:

Decorators - they're usually generic, so you can't specify the arguments upfront:

<pre><code>def decorator(old):
 def new(*args, **kwargs):
 # ...
 return old(*args, **kwargs)
 return new
</code></pre>

Places where you want to do magic with an unknown number of keyword arguments. Django's ORM does that, e.g.:

<pre><code>Model.objects.filter(foo__lt = 4, bar__iexact = 'bar')
</code></pre>

blocks|key|3090532|text|一个例子是实现python-argument-binders，如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3090533|3090534|from函数工具导入部分>>>定义f(a，b)：...8|blockquote|3090535|
+a%2Bb+>>>+p=+partial(f，1，2)+>>>+p()+3+>>>+p2+=+partial(f，1)+>>>+p2(7)+return|3090536|这来自functools.partial+python文档:+partial与下面的impl“相对等效”：|3090537|3090538|+def+partial(+func，*+args，**关键字)：def+newfunc(*fargs，**f关键字)：newfunc=+keywords.copy()+newkeywords.update(f关键字)+return+func(*(args+%2B+fargs)，**newfunc)+newfunc.func+=func+newfunc.args+=args+newfunc.keywords+=+keywords+return+newfunc|3090539|3090540|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/277922/python-argument-binders|1|http://docs.python.org/library/functools.html?highlight=functools#functools.partial^0|7|N|0|0|0|0|0|3|H|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|D|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|14|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|L|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|M|3|N|5|G|7|1B|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]|X|$5|S|T|U|C|$V|Y]]]]

One example is implementing <a href="https://stackoverflow.com/questions/277922/python-argument-binders">python-argument-binders</a>, used like this:

<blockquote>
<pre><code>&gt;&gt;&gt; from functools import partial
&gt;&gt;&gt; def f(a, b):
... return a+b
&gt;&gt;&gt; p = partial(f, 1, 2)
&gt;&gt;&gt; p()
3
&gt;&gt;&gt; p2 = partial(f, 1)
&gt;&gt;&gt; p2(7)
8
</code></pre>
</blockquote>

This is from the <a href="http://docs.python.org/library/functools.html?highlight=functools#functools.partial" rel="nofollow noreferrer">functools.partial</a> python docs: partial is 'relatively equivalent' to this impl:

<blockquote>
<pre><code>def partial(func, *args, **keywords):
 def newfunc(*fargs, **fkeywords):
 newkeywords = keywords.copy()
 newkeywords.update(fkeywords)
 return func(*(args + fargs), **newkeywords)
 newfunc.func = func
 newfunc.args = args
 newfunc.keywords = keywords
 return newfunc
</code></pre>
</blockquote>

blocks|key|3090573|text|出于一系列原因，您可能希望接受近乎任意的命名参数--这正是**kw表单允许您做的事情。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3090574|最常见的原因是将参数直接传递给要包装的其他函数(装饰器是这种情况的一个例子，但不是唯一的一个！)+--在这种情况下，**kw松开了包装器和包装器之间的耦合，因为包装器不必知道或关心包装器的所有参数。这是另一个完全不同的原因：|3090575|d+=+dict(a=1,+b=2,+c=3,+d=4)|code-block|syntax|javascript|3090576|如果所有的名字都必须事先知道，那么这种方法显然不可能存在，对吧？顺便说一句，在适用的情况下，我更喜欢这种以文字字符串为关键字的字典制作方式：|3090577|d+=+{'a':+1,+'b':+2,+'c':+3,+'d':+4}|3090578|原因很简单，因为后者的标点符号很多，因此可读性较差。|3090579|当接受**kwargs的最佳理由都不适用时，不要接受它:就这么简单。如果没有充分的理由允许调用者传递具有任意名称的额外命名参数，请不要允许这种情况发生--只要避免在def语句中将**kw表单放在函数签名的末尾即可。|3090580|至于在调用中使用**kw，它允许您将必须传递的命名参数的确切集合放在一个字典中，每个参数都有相应的值，独立于单个调用点，然后在单个调用点使用该字典。比较：|3090581|if+x:+kw['x']+=+x
if+y:+kw['y']+=+y
f(**kw)|3090582|至：|3090583|if+x:
++if+y:
++++f(x=x,+y=y)
++else:
++++f(x=x)
else:
++if+y:
++++f(y=y)
++else:
++++f()|3090584|即使只有两种可能性(而且是最简单的一种！)，**kw的缺乏已经使第二种选择变得完全站不住脚和无法容忍--想象一下当有六种可能性时，它会如何发展，可能是在稍微丰富的交互中……没有**kw，在这种情况下，生活将是绝对的地狱！|3090585|entityMap^0|T|4|0|1M|4|0|0|0|0|0|3|8|2A|3|2H|4|0|8|4|0|0|0|0|M|4|2G|4|0^^$0|@$1|2|3|4|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|19|8|@$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|1C|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1D|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|1E|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1F|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|W|3|X|5|J|7|1Q|8|@]|D|@]|E|$K|L]]|$1|Y|3|Z|5|6|7|1R|8|@]|D|@]|E|$]]|$1|10|3|11|5|J|7|1S|8|@]|D|@]|E|$K|L]]|$1|12|3|13|5|6|7|1T|8|@$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]]|D|@]|E|$]]|$1|14|3|-4|5|6|7|1Y|8|@]|D|@]|E|$]]]|15|$]]

You may want to accept nearly-arbitrary named arguments for a series of reasons -- and that's what the <code>**kw</code> form lets you do.

The most common reason is to pass the arguments right on to some other function you're wrapping (decorators are one case of this, but FAR from the only one!) -- in this case, <code>**kw</code> loosens the coupling between wrapper and wrappee, as the wrapper doesn't have to know or care about all of the wrappee's arguments. Here's another, completely different reason:

<pre><code>d = dict(a=1, b=2, c=3, d=4)
</code></pre>

if all the names had to be known in advance, then obviously this approach just couldn't exist, right? And btw, when applicable, I much prefer this way of making a dict whose keys are literal strings to:

<pre><code>d = {'a': 1, 'b': 2, 'c': 3, 'd': 4}
</code></pre>

simply because the latter is quite punctuation-heavy and hence less readable.

When none of the excellent reasons for accepting <code>**kwargs</code> applies, then don't accept it: it's as simple as that. IOW, if there's no good reason to allow the caller to pass extra named args with arbitrary names, don't allow that to happen -- just avoid putting a <code>**kw</code> form at the end of the function's signature in the <code>def</code> statement.

As for using <code>**kw</code> in a call, that lets you put together the exact set of named arguments that you must pass, each with corresponding values, in a dict, independently of a single call point, then use that dict at the single calling point. Compare:

<pre><code>if x: kw['x'] = x
if y: kw['y'] = y
f(**kw)
</code></pre>

to:

<pre><code>if x:
 if y:
 f(x=x, y=y)
 else:
 f(x=x)
else:
 if y:
 f(y=y)
 else:
 f()
</code></pre>

Even with just two possibilities (and of the very simplest kind!), the lack of <code>**kw</code> is aleady making the second option absolutely untenable and intolerable -- just imagine how it plays out when there half a dozen possibilities, possibly in slightly richer interaction... without <code>**kw</code>, life would be absolute hell under such circumstances!

blocks|key|3090640|text|常见的情况有两种：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3090641|首先:您包装了另一个函数，该函数接受许多关键字参数，但您只需传递它们：|3090642|def+my_wrapper(a,+b,+**kwargs):
++++do_something_first(a,+b)
++++the_real_function(**kwargs)|code-block|syntax|javascript|3090643|第二:您愿意接受任何关键字参数，例如，在对象上设置属性：|3090644|class+OpenEndedObject:
++++def+__init__(self,+**kwargs):
++++++++for+k,+v+in+kwargs.items():
++++++++++++setattr(self,+k,+v)

foo+=+OpenEndedObject(a=1,+foo='bar')
assert+foo.a+==+1
assert+foo.foo+==+'bar'|3090645|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

There are two common cases:

First: You are wrapping another function which takes a number of keyword argument, but you are just going to pass them along:

<pre><code>def my_wrapper(a, b, **kwargs):
 do_something_first(a, b)
 the_real_function(**kwargs)
</code></pre>

Second: You are willing to accept any keyword argument, for example, to set attributes on an object:

<pre><code>class OpenEndedObject:
 def __init__(self, **kwargs):
 for k, v in kwargs.items():
 setattr(self, k, v)

foo = OpenEndedObject(a=1, foo='bar')
assert foo.a == 1
assert foo.foo == 'bar'
</code></pre>

blocks|key|329080|text|您可能希望使用**kwargs+(和*args)的另一个原因是，如果您在子类中扩展现有方法。您希望将所有现有参数传递给超类的方法，但又希望确保即使签名在将来的版本中发生更改，您的类也能继续工作：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|329081|class+MySubclass(Superclass):
++++def+__init__(self,+*args,+**kwargs):
++++++++self.myvalue+=+kwargs.pop('myvalue',+None)
++++++++super(MySubclass,+self).__init__(*args,+**kwargs)|code-block|syntax|javascript|329082|entityMap^0|7|8|I|5|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|L|$]]

Another reason you might want to use <code>**kwargs</code> (and <code>*args</code>) is if you're extending an existing method in a subclass. You want to pass all the existing arguments onto the superclass's method, but want to ensure that your class keeps working even if the signature changes in a future version:

<pre><code>class MySubclass(Superclass):
 def __init__(self, *args, **kwargs):
 self.myvalue = kwargs.pop('myvalue', None)
 super(MySubclass, self).__init__(*args, **kwargs)
</code></pre>

blocks|key|3090721|text|下面是我在CGI+Python中使用的一个示例。我创建了一个将**kwargs带到__init__函数的类。这使我能够在服务器端使用类模拟DOM：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3090722|document+=+Document()
document.add_stylesheet('style.css')
document.append(Div(H1('Imagist\'s+Page+Title'),+id+=+'header'))
document.append(Div(id='body'))|code-block|syntax|javascript|3090723|惟一的问题是您不能执行以下操作，因为class是一个Python关键字。|3090724|Div(class+=+'foo')|3090725|解决方案是访问底层字典。|3090726|Div(**{'class':'foo'})|3090727|我并不是说这是对该功能的“正确”使用。我要说的是，像这样的功能可以通过各种不可预见的方式来使用。|3090728|entityMap^0|V|8|15|8|0|0|I|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|M|3|N|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|16|8|@]|D|@]|E|$]]|$1|Q|3|R|5|H|7|17|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|18|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|V|$]]

Here's an example, I used in CGI Python. I created a class that took <code>**kwargs</code> to the <code>__init__</code> function. That allowed me to emulate the DOM on the server-side with classes:

<pre><code>document = Document()
document.add_stylesheet('style.css')
document.append(Div(H1('Imagist\'s Page Title'), id = 'header'))
document.append(Div(id='body'))
</code></pre>

The only problem is that you can't do the following, because <code>class</code> is a Python keyword.

<pre><code>Div(class = 'foo')
</code></pre>

The solution is to access the underlying dictionary.

<pre><code>Div(**{'class':'foo'})
</code></pre>

I'm not saying that this is a "correct" usage of the feature. What I'm saying is that there are all kinds of unforseen ways in which features like this can be used.

blocks|key|3090736|text|这是另一个典型的例子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3090737|MESSAGE+=+"Lo+and+behold!+A+message+{message!r}+came+from+{object_}+with+data+{data!r}."

def+proclaim(object_,+message,+data):
++++print(MESSAGE.format(**locals()))|code-block|syntax|javascript|3090738|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

And here's another typical example:

<pre><code>MESSAGE = "Lo and behold! A message {message!r} came from {object_} with data {data!r}."

def proclaim(object_, message, data):
 print(MESSAGE.format(**locals()))
</code></pre>

I come from a background in static languages. Can someone explain (ideally through example) the real world advantages of using **kwargs over named arguments?

To me it only seems to make the function call more ambiguous. Thanks.

Why use **kwargs in python? What are some real world advantages over using named arguments?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有静态语言的背景。有人能解释一下(最好是通过示例)使用**kwargs而不是命名参数的实际优势吗？对我来说，这只会让函数调用变得更加模糊。谢谢。

问为什么要在python中使用**kwargs？与使用命名参数相比，现实世界中有哪些优势？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么要在python中使用**kwargs？与使用命名参数相比，现实世界中有哪些优势？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么要在python中使用**kwargs？与使用命名参数相比，现实世界中有哪些优势？
EN