blocks|key|1448744|text|这并不是说它不能接受，而是dicts不是以这种方式实现的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1448745|如果你看看Django的ORM，你会发现它大量使用了链接。这并不令人沮丧，你甚至可以从dict继承，如果你真的想要的话，只需要重写update来做更新和return+self。|1448746|class+myDict(dict):
++++def+update(self,+*args):
++++++++dict.update(self,+*args)
++++++++return+self|code-block|syntax|javascript|1448747|entityMap^0|D|5|0|17|4|1T|6|24|B|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|N|$]]

Its not that it isn't acceptable, but rather that <code>dicts</code> weren't implemented that way.

If you look at Django's ORM, it makes extensive use of chaining. Its not discouraged, you could even inherit from <code>dict</code> and only override <code>update</code> to do update and <code>return self</code>, if you really want it.

<pre><code>class myDict(dict):
 def update(self, *args):
 dict.update(self, *args)
 return self
</code></pre>

blocks|key|1234080|text|按照惯例，Python的API区分了过程和函数。函数从它们的参数(包括任何目标对象)计算出新值；过程修改对象并且不返回任何东西(即它们返回None)。所以过程有副作用，函数没有。update是一个过程，因此它不返回值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1234081|这样做的动机是，否则，你可能会得到不想要的副作用。考虑一下|1234082|bar+=+foo.reverse()|code-block|syntax|javascript|1234083|如果reverse+(就地反转列表)也会返回列表，用户可能会认为reverse返回一个分配给bar的新列表，而不会注意到foo也会被修改。通过使反向返回为None，他们立即认识到条形不是反向的结果，并将更接近反向的效果。|1234084|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Python's API, by convention, distinguishes between procedures and functions. Functions compute new values out of their parameters (including any target object); procedures modify objects and don't return anything (i.e. they return None). So procedures have side effects, functions don't. update is a procedure, hence it doesn't return a value.

The motivation for doing it that way is that otherwise, you may get undesirable side effects. Consider

<pre><code>bar = foo.reverse()
</code></pre>

If reverse (which reverses the list in-place) would also return the list, users may think that reverse returns a new list which gets assigned to bar, and never notice that foo also gets modified. By making reverse return None, they immediately recognize that bar is not the result of the reversal, and will look more close what the effect of reverse is.

blocks|key|1448885|text|>>>+dict_merge+=+lambda+a,b:+a.update(b)+or+a
>>>+dict_merge({'a':1,+'b':3},{'c':5})
{'a':+1,+'c':+5,+'b':+3}|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1448886|注意，除了返回合并的dict之外，它还就地修改了第一个参数。所以dict_merge(+a，b)会修改a。|unstyled|1448887|当然，您也可以全部内联完成：|1448888|>>>+(lambda+a,b:+a.update(b)+or+a)({'a':1,+'b':3},{'c':5})
{'a':+1,+'c':+5,+'b':+3}|1448889|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$B|C]]|$1|K|3|-4|5|F|7|Q|8|@]|9|@]|A|$]]]|L|$]]

<pre><code>&gt;&gt;&gt; dict_merge = lambda a,b: a.update(b) or a
&gt;&gt;&gt; dict_merge({'a':1, 'b':3},{'c':5})
{'a': 1, 'c': 5, 'b': 3}
</code></pre>

Note that as well as returning the merged dict, it modifies the first parameter in-place. So dict_merge(a,b) will modify a.

Or, of course, you can do it all inline:

<pre><code>&gt;&gt;&gt; (lambda a,b: a.update(b) or a)({'a':1, 'b':3},{'c':5})
{'a': 1, 'c': 5, 'b': 3}
</code></pre>

blocks|key|1448893|text|import+itertools
dict_merge+=+lambda+*args:+dict(itertools.chain(*[d.iteritems()+for+d+in+args]))|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1448894|unstyled|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$B|C]]|$1|D|3|-4|5|E|7|H|8|@]|9|@]|A|$]]]|F|$]]

<pre><code>import itertools
dict_merge = lambda *args: dict(itertools.chain(*[d.iteritems() for d in args]))
</code></pre>

blocks|key|1448917|text|尽可能接近您提出的解决方案|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1448918|from+collections+import+ChainMap

return+self.add_award(ChainMap(award_dict,+{
++++"name"+:+name,
++++"description"+:+desc_string+%25+count,
++++"points"+:+points,
++++"parent_award"+:+parent,
}),+siteAlias,+alias).award|code-block|syntax|javascript|1448919|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|$]]

as close to your proposed solution as I could get

<pre><code>from collections import ChainMap

return self.add_award(ChainMap(award_dict, {
 "name" : name,
 "description" : desc_string % count,
 "points" : points,
 "parent_award" : parent,
}), siteAlias, alias).award
</code></pre>

blocks|key|1234241|text|我自己也在Python3.4中尝试过(所以我不能使用花哨的{**dict_1,+**dict_2}语法)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1234242|我希望能够在字典中使用非字符串键，并提供任意数量的字典。|1234243|另外，我想做一本新的字典，所以我选择不使用collections.ChainMap+(这也是我最初不想使用dict.update的原因。|1234244|这是我最终写的：|1234245|def+merge_dicts(*dicts):
++++all_keys++=+set(k+for+d+in+dicts+for+k+in+d.keys())
++++chain_map+=+ChainMap(*reversed(dicts))
++++return+{k:+chain_map[k]+for+k+in+all_keys}

merge_maps({'1':+1},+{'2':+2,+'3':+3},+{'1':+4,+'3':+5})
#+{'1':+4,+'3':+5,+'2':+2}|code-block|syntax|javascript|1234246|entityMap^0|T|K|0|0|L|K|1H|B|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|11|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|12|8|@]|D|@]|E|$O|P]]|$1|Q|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|R|$]]

Just been trying this myself in Python 3.4 (so wasn't able to use the fancy <code>{**dict_1, **dict_2}</code> syntax). 

I wanted to be able to have non-string keys in dictionaries as well as provide an arbitrary amount of dictionaries.

Also, I wanted to make a new dictionary so I opted to not use <code>collections.ChainMap</code> (kinda the reason I didn't want to use <code>dict.update</code> initially.

Here's what I ended up writing:

<pre><code>def merge_dicts(*dicts):
 all_keys = set(k for d in dicts for k in d.keys())
 chain_map = ChainMap(*reversed(dicts))
 return {k: chain_map[k] for k in all_keys}

merge_maps({'1': 1}, {'2': 2, '3': 3}, {'1': 4, '3': 5})
# {'1': 4, '3': 5, '2': 2}
</code></pre>

blocks|key|1448998|text|这很简单，因为：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1448999|(lambda+d:+d.update(dict2)+or+d)(d1)|code-block|syntax|javascript|1449000|或者，如果不修改字典很重要：|1449001|(lambda+d:+d.update(dict2)+or+d)(d1.copy())|1449002|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

This is easy as:
<pre><code>(lambda d: d.update(dict2) or d)(d1)
</code></pre>
Or, if it is important not to modify the dictionary:
<pre><code>(lambda d: d.update(dict2) or d)(d1.copy())
</code></pre>

blocks|key|1449048|text|对于那些来晚了的人，我把一些时间安排在一起(Py3.7)，表明当输入被保留时，基于.update()的方法看起来要快一点(~5%25)，当只是就地更新时，速度明显快(~30%25)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1449049|像往常一样，所有的基准测试都应该持保留态度。|1449050|def+join2(dict1,+dict2,+inplace=False):
++++result+=+dict1+if+inplace+else+dict1.copy()
++++result.update(dict2)
++++return+result


def+join(*items):
++++iter_items+=+iter(items)
++++result+=+next(iter_items).copy()
++++for+item+in+iter_items:
++++++++result.update(item)
++++return+result


def+update_or(dict1,+dict2):
++++return+dict1.update(dict2)+or+dict1


d1+=+{i:+str(i)+for+i+in+range(1000000)}
d2+=+{str(i):+i+for+i+in+range(1000000)}

%25timeit+join2(d1,+d2)
#+258+ms+±+1.47+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)

%25timeit+join(d1,+d2)
#+262+ms+±+2.97+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)

%25timeit+dict(d1,+**d2)
#+267+ms+±+2.74+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)

%25timeit+{**d1,+**d2}
#+267+ms+±+1.84+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)|code-block|syntax|javascript|1449051|就地操作的计时有点棘手，因此需要根据额外的复制操作对其进行修改(第一个计时仅供参考)：|1449052|%25timeit+dd+=+d1.copy()
#+44.9+ms+±+495+µs+per+loop+(mean+±+std.+dev.+of+7+runs,+10+loops+each)

%25timeit+dd+=+d1.copy();+join2(dd,+d2)
#+296+ms+±+2.05+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)

%25timeit+dd+=+d1.copy();+join2(dd,+d2,+True)
#+234+ms+±+1.02+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)

%25timeit+dd+=+d1.copy();+update_or(dd,+d2)
#+235+ms+±+1.6+ms+per+loop+(mean+±+std.+dev.+of+7+runs,+1+loop+each)|1449053|entityMap^0|15|9|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|Q|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|R|$]]

For those coming late to the party, I had put some timing together (Py 3.7), showing that <code>.update()</code> based methods look a bit (~5%) faster when inputs are preserved and noticeably (~30%) faster when just updating in-place.

As usual, all the benchmarks should be taken with a grain of salt.

<pre><code>def join2(dict1, dict2, inplace=False):
 result = dict1 if inplace else dict1.copy()
 result.update(dict2)
 return result


def join(*items):
 iter_items = iter(items)
 result = next(iter_items).copy()
 for item in iter_items:
 result.update(item)
 return result


def update_or(dict1, dict2):
 return dict1.update(dict2) or dict1


d1 = {i: str(i) for i in range(1000000)}
d2 = {str(i): i for i in range(1000000)}

%timeit join2(d1, d2)
# 258 ms ± 1.47 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit join(d1, d2)
# 262 ms ± 2.97 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit dict(d1, **d2)
# 267 ms ± 2.74 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit {**d1, **d2}
# 267 ms ± 1.84 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
</code></pre>

The timings for the in-place operations are a bit trickier, so it would need to be modified along an extra copy operation (the first timing is just for reference):

<pre><code>%timeit dd = d1.copy()
# 44.9 ms ± 495 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit dd = d1.copy(); join2(dd, d2)
# 296 ms ± 2.05 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit dd = d1.copy(); join2(dd, d2, True)
# 234 ms ± 1.02 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit dd = d1.copy(); update_or(dd, d2)
# 235 ms ± 1.6 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
</code></pre>

I 'm trying to do :

<pre><code>award_dict = {
 "url" : "http://facebook.com",
 "imageurl" : "http://farm4.static.flickr.com/3431/3939267074_feb9eb19b1_o.png",
 "count" : 1,
}

def award(name, count, points, desc_string, my_size, parent) :
 if my_size &gt; count :
 a = {
 "name" : name,
 "description" : desc_string % count,
 "points" : points,
 "parent_award" : parent,
 }
 a.update(award_dict)
 return self.add_award(a, siteAlias, alias).award
</code></pre>

But if felt really cumbersome in the function, and I would have rather done :

<pre><code> return self.add_award({
 "name" : name,
 "description" : desc_string % count,
 "points" : points,
 "parent_award" : parent,
 }.update(award_dict), siteAlias, alias).award
</code></pre>

Why doesn't update return the object so you can chain? 

JQuery does this to do chaining. Why isn't it acceptable in python?

Why doesn't a python dict.update() return the object?

我想做的是：award_dict = {    "url" : "http://facebook.com",    "imageurl" : "http://farm4.static.flickr.com/3431/3939267074_feb9eb19b1_o.png",    "count" : 1,}def aw...

问为什么python dict.update()不返回对象？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么python dict.update()不返回对象？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么python dict.update()不返回对象？
EN