PEP 584 – Add + and – operators to the built-in dict class

164 pointsby Ivoahabout 6 years ago

18 comments

kbdabout 6 years ago

> An alternative to the + operator is the pipe | operator, which is used for set union. This suggestion did not receive much support on Python-Ideas.That's disappointing. It's always been on my Python wish list that dicts would subclass sets, as dicts are essentially sets with values attached. Pretty much everywhere you can use a set you can use a dict and it acts like the set of its keys. For example:<pre><code> >>> s = {'a','b','c'} >>> d = {i: i.upper() for i in s} >>> list(d) == list(s) True </code></pre> Dictionaries have been moving in this more ergonomic direction for a while. Originally, to union two dictionaries you had to say:<pre><code> >>> d2 = {'d': 'D'} >>> >>> d3 = d.copy() >>> d3.update(d2) >>> d3 {'a': 'A', 'b': 'B', 'c': 'C', 'd': 'D'} </code></pre> Nowadays, as the PEP points out, you can just say:<pre><code> >>> {**d, **d2} {'a': 'A', 'b': 'B', 'c': 'C', 'd': 'D'} </code></pre> There's no reason you shouldn't have always been able to say d | d2, same as sets. Now I finally get my wish that dictionaries will behave more similarly to sets and they use the wrong set of operators.

评论 #19317985 未加载

评论 #19317654 未加载

评论 #19317519 未加载

评论 #19317916 未加载

评论 #19317475 未加载

评论 #19323519 未加载

评论 #19317494 未加载

评论 #19318267 未加载

评论 #19317470 未加载

评论 #19317530 未加载

zestypingabout 6 years ago

len(dict1 + dict2) does not equal len(dict1) + len(dict2) so using the + operator is nonsense.The operators should be |, &, and -, exactly as for sets, and the behaviour defined with just three rules:1. The keys of dict1 [op] dict2 are the elements of dict1.keys() [op] dict2.keys().2. The values of dict2 overwrite the values of dict1.3. When either operand is a set, it is treated as a dict whose values are None.This yields many useful operations and is simple to explain.merge and update:<pre><code> {'a': 1, 'b': 2} | {'b': 3, 'c': 4} => {'a': 1, 'b': 3, 'c': 4} </code></pre> pick some items:<pre><code> {'a': 1, 'b': 2} & {'b': 3, 'c': 4} => {'b': 3} </code></pre> remove some items:<pre><code> {'a': 1, 'b': 2} - {'b': 3, 'c': 4} => {'a': 1} </code></pre> reset values of some keys:<pre><code> {'a': 1, 'b': 2} | {'b', 'c'} => {'a': 1, 'b': None, 'c': None} </code></pre> ensure all keys are present:<pre><code> {'b', 'c'} | {'a': 1, 'b': 2} => {'a': 1, 'b': 2, 'c': None} </code></pre> pick some items:<pre><code> {'b', 'c'} | {'a': 1, 'b': 2} => {'b': 2} </code></pre> remove some items:<pre><code> {'a': 1, 'b': 2} - {'b', 'c'} => {'a': 1}</code></pre>

评论 #19318305 未加载

评论 #19321532 未加载

评论 #19318205 未加载

评论 #19317842 未加载

评论 #19318121 未加载

jerfabout 6 years ago

Unlike some of the other commenters, I'm fine with the + specification. + hasn't been commutative in Python for a long time.But the - bothers me, and nobody else seems to have mentioned this. {"a": 1} - {"a": 1} = {}, sure, but it is way less obvious to me that {"a": 1} - {"a": 2} = {}, and not {"a": 1}. If you consider dictionaries as an unordered list of tuples (key, value) where keys happen to be unique and as a result of that you get nice O()-factors on access, that doesn't make sense. You went to remove ("a", 2), but saw ("a", 1) and thought, "eh, close enough". But it's not the same thing.If you think of a dict as a set that happens to have associated values, the specification makes more sense, but if you dig into that line of thought, that turns out to be a rather weird way of thinking of them. Values really shouldn't be thought of as second-class citizens of a dict. If you are going to go this route though, {"a": 1} - {"a"} = {} (where the right-hand side is a set) actually makes more sense, without the spurious value on the right-hand side.I'd actually rather conceive of the - operation as a "dict minus an iterable that will yield keys to remove". This has the advantage of recovering the original {"a": 1} - {"a": 2} = {} semantics that probably is what people want in practice, just via a different method. But locking the right-hand side to a dict makes it weird.

评论 #19319942 未加载

评论 #19320309 未加载

wodenokotoabout 6 years ago

> Analogously with list addition, the operator version is more restrictive, and requires that both arguments are dicts, while the augmented assignment version allows anything the update method allows, such as iterables of key/value pairs.<pre><code> >>> d + [('spam', 999)] Traceback (most recent call last): ... TypeError: can only merge dict (not "list") to dict >>> d += [('spam', 999)] >>> print(d) {'spam': 999, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'} </code></pre> While I get the "Because this is what lists do"-argument, I am still wondering why there is a difference in the types allowed for `+` and `+=`?

评论 #19317374 未加载

评论 #19321477 未加载

ameliusabout 6 years ago

For sets I can understand what + and - means: you can add or subtract the sets (not add or remove an element directly). This should be like lists, e.g.<pre><code> [10,20] + [30] </code></pre> But what + and - would mean in the case of dicts is obscure. Better to just use full method names imho.

评论 #19318233 未加载

评论 #19317370 未加载

comexabout 6 years ago

The + operator looks great – I've personally experienced the papercut this solves multiple times, where it would be most natural to have "combine two dicts" operator:<pre><code> return {'a': 'b'} + other_dict </code></pre> but instead I had to assign to a variable and mutate with .update(), which is much more verbose:<pre><code> x = {'a': 'b'} x.update(other_dict) return x </code></pre> However, I was working in Python 2; Python 3 has<pre><code> {'a': 'b', **other_dict} </code></pre> and even<pre><code> {**one_dict, **other_dict} </code></pre> though the PEP mentions that the latter doesn't work in all circumstances. Still, it will be nice to have a more general operator; I personally don't really care whether it's called + or |.On the other hand, the - operator seems... strange, in that it only considers the keys of its right-hand argument, and ignores the values. Seems like a footgun.

pettersabout 6 years ago

I think overloading + so that a + b != b + a is problematic.I know this is the case for strings and lists, but those cases are very well established.

评论 #19318487 未加载

评论 #19317980 未加载

评论 #19317900 未加载

评论 #19318238 未加载

mk89about 6 years ago

Reminds me of Scala Maps[0].Edit: after reading more carefully,...> Analogously with list addition, the operator version is more restrictive, and requires that both arguments are dicts, while the augmented assignment version allows anything the update method allows, such as iterables of key/value pairs.But why? Consistency in API behavior is important, and as a user I don't want to have to read that I can add lists of pairs only with assignments. I hope the draft gets fixed.[0]: <a href="https://docs.scala-lang.org/overviews/collections/maps.html" rel="nofollow">https://docs.scala-lang.org/overviews/collections/maps.html</a>

评论 #19317505 未加载

评论 #19318198 未加载

speedplaneabout 6 years ago

Python continues to introduce more non-intuitive semantics that may be a small boon to the the expert class of programmers, but comes at the expense of ease of adoption for beginners. It started by making everything a generator, which are not very easy to master, and for which there were plenty of perfectly good substitutes (e.g., xrange, iteritems). And now you "add" sets of items (which you can't do in math) and when the update function worked well.Python 3 is such a sad mess.

评论 #19317995 未加载

评论 #19320755 未加载

评论 #19317539 未加载

评论 #19320356 未加载

评论 #19317429 未加载

评论 #19317440 未加载

rurbanabout 6 years ago

dict.merge(d, ...) and dict.diff(d, ...) are more expressive and have a cleaner semantic.overloading arithmetic ops for string, list or dict ops might only look elegant at first sight, but discrimination needs to be done at runtime, slowing down the most important arithmetic ops, and do not help much the casual code reader. It also cannot be used in normal python code as older python will fail, only in special internal code.normal method names can be provided by external modules, so they are backwards compatible and will find more widely adoption.

评论 #19318224 未加载

评论 #19317847 未加载

s17nabout 6 years ago

It's weird to use + for a non-commutative operation, right?

评论 #19317455 未加载

评论 #19318651 未加载

评论 #19318679 未加载

js2about 6 years ago

> The implementation will be in C. (The author of this PEP would like to make it known that he is not able to write the implementation.)I hope this is for a reason other than the author being unfamiliar with C. Otherwise the author is cheating themselves, because adding functionality to an existing code base is probably my favorite motivator for learning a new language.

评论 #19325560 未加载

varelazabout 6 years ago

I don't like the idea, because a + b should produce new list c without modification of both. Which is not memory optimal and cost of it is not obvious. Also dict is used a lot for sub classes and that could break a lot of existing functionality with potentially no benefit for most of the developers. I don't think that merging is very common operation for dicts and even so it could be done with 1 or 2 update function calls, but that will be obvious in that case, while '+' in deeps of duck typing code is not. Also absence of '+' operation for dicts is kind of guard for type validation in case if someone passed dict instead of integer. Which is pretty common when you parse some JSON from client.

评论 #19318216 未加载

sametmaxabout 6 years ago

One of the long awaited features, rejected by Guido many times, and finally accepted. Maybe we'll get list.get(), functools.partial() as a c written builtin, pathlib.Path() as a primitive or inline try/except, one day.

评论 #19318188 未加载

mrocheabout 6 years ago

<pre><code> def __add__(self, other): if isinstance(other, dict): new = type(self)() # May be a subclass of dict. new.update(self) new.update(other) return new </code></pre> Is there something I’m missing? To me it would be cleaner and more memory/time performant to just `self.update(other)` rather than having a third list instance at operation time. But that would really only apply if you have truly massive dicts.

评论 #19319266 未加载

projektfuabout 6 years ago

Is there a real-world demand for the dictionary difference operator or is it just being proposed for completeness? I'm racking my brain to think of reasons to use it that would be more expressive than simply giving a list of keys to delete.

Grue3about 6 years ago

I like this. The current kwargs syntax is very confusing since it behaves very differently from funcall kwargs syntax.

评论 #19317755 未加载

IceDaneabout 6 years ago

This is what you get when you try to implement general mathematical concepts in a language that is horrible at expressing them. What a clusterfuck python is going to be in a few years.