Issue 917095: dict type concat function (original) (raw)

Created on 2004-03-16 05:33 by troy_melhase, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
dict_concat.patch troy_melhase,2004-03-16 05:33
Messages (6)
msg45578 - (view) Author: Troy Melhase (troy_melhase) Date: 2004-03-16 05:33
Adds a function to dictobject.c that allows python expressions like: >>> d = {2:3} >>> d += {4:5} >>> d {2: 3, 4: 5} and like: >>> d = {2:3} >>> e = d + {6:7} >>> e {2: 3, 6: 7} A few points: * I don't know much C, and this patch is probably implemented much more appropriately by someone who does * I don't know if there's a good reason that the dict type doesn't already supply this; if that's the case, I'd be interested to know why not * Lib/test/test_builtin.py fails (as it should) after applying this patch Please advise, and thanks!
msg45579 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-03-16 11:08
Logged In: YES user_id=80475 I recommend against this for several reasons: 1) adds new syntax but not new functionality 2) concept doesn't usefully extend to - and * 3) writing d.update(x) is clearer and more flexible -- in Py2.4, update() can take the same arguments as dict() 4) no use cases showing the + operator to be more expressive 5) possibly confusing given the | operator is used for sets 6) {1:4}+{1:7} is not commutative and unlike list addition, there is no underlying order that makes the non- commutativity obvious. IOW, the operator may introduce a new class of hard to find bugs. If for some reason this gets approved, please assign back to me for implementation, documentation, and unittests.
msg45580 - (view) Author: Troy Melhase (troy_melhase) Date: 2004-03-16 19:22
Logged In: YES user_id=548370 1) adds new syntax but not new functionality 3) writing d.update(x) is clearer and more flexible -- in Py2.4, update() can take the same arguments as dict() The same is true of list.extend and list.append. After years of writing python code, I still forget that I can't add dictionaries to one another, which for me at least, violates the principle of least surprise. The patch doesn't provide the same behavior as the update method; when adding two dicts, a third dict is returned. Only in the case of augmented assignment is the update method similar. Moreover, every other basic container-ish type supports addition of the same type (or similar type). It seems to me that the dict type is missing a feature, not the other way around. 2) concept doesn't usefully extend to - and * I could see it extending to -, but you're right that it doesn't extend to *. 5) possibly confusing given the | operator is used for sets I don't understand this point, could you elaborate? 6) {1:4}+{1:7} is not commutative and unlike list addition, there is no underlying order that makes the non- commutativity obvious. IOW, the operator may introduce a new class of hard to find bugs. But unlike list addition, dict addition is commutative: >>> d = {2:3} >>> e = {4:5} >>> d + e == e + d True Thanks for looking; could you advise again?
msg45581 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2004-03-16 19:34
Logged In: YES user_id=593130 I am usually big on orthogonality, but it never occurred to me that dicts should be addible, although sets are. What should be the result of {1:2} + {1:3}? If not something like {1:set (2,3)}, the operator is *not* commutative. The reference to sets and | is that is used, I believe, for set union (addition) (and & for intersection). So, if there were to be a dict union operator, the symbol should be rather than +.
msg45582 - (view) Author: Troy Melhase (troy_melhase) Date: 2004-03-17 07:33
Logged In: YES user_id=548370 Doh. You're right about it being not commutative. I hadn't considered the example you provided. I agree that the | operator makes more sense. I'll close this patch until I'm up to implementing that. Thanks, Terry, Raymond!
msg45583 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-03-17 11:00
Logged In: YES user_id=80475 The non-commutativity issue also applies to the | operator. I wouldn't spend time on a second patch unless there were significant new functionality, compelling use cases, a natural readability for expressions involving the operator, and an approach that suggests non-commutative update behavior. IOW, I wouldn't spend time on a second patch ;-)
History
Date User Action Args
2022-04-11 14:56:03 admin set github: 40036
2004-03-16 05:33:23 troy_melhase create