Python Forum

here is an idea that i sure wanted to code in tonight's project.

while doing some scanning i put some info into a dictionary. but there was one point where i needed to put a few key:value pairs in at the same time, so i ended up coding something like:

    info.update({'freq':freq,'band':band,'mode':mode,'power':power,'antenna':antnum})

but, because the first coding pass had used a list, i wanted to code it more like:

  info += {'freq':freq,'band':band,'mode':mode,'power':power,'antenna':antnum}

the meaning is the same, but because i had been coding some += operations already, my brain was ready to just keep doing so. if this were being done with a set, then |= might make more sense. and due to the similarity between a set and a dictionary, it might make more sense to some to use |= instead of += to join one dictionary to another.

the opinion i am soliciting is whether this kind syntactic sugar should be a [art of the language, if it were the developers asking for a public vote. unfortunately, i won't be able to offer much justification. it doesn't shorten much, but it does remove () from around {} which makes it easier to read, IMHO.

Here's my problem with it: dictionaries are like sets (the keys of a dictionary are a set). So it should be |=, not +=, to match set.union(), since you are creating the union of the keys. But for sets, s1 | s2 == s2 | s1 (union is commutative). But that wouldn't necessarily be the case for dictionaries. If they share keys, update is not commutative.

i agree that updating a dictionary is non-commutative. but does that mean it can't use |= ?? must | be used only in commutative cases?

I've found (or my search engine found) a nice discussion about this topic.

4 loc

class Dict(dict):
    def __iadd__(self, other):
        self.update(other)
        return self

If you want to monkeypatch:

dict = Dict

Good luck with it. I don't like monkey patching.

Another approach:

d1 = {'freq':'freq','band':'band','mode':'mode','power':'power','antenna':'antnum'}
d2 = {'freq':'freq','band':'band','mode':'mode','power':'power','antenna':'antnum'}
d3 = {**d1, **d2}

I like the iadd approach.
To have it as implementation in Python Language would be nice.

(Nov-21-2018, 08:07 PM)Skaperen Wrote: [ -> ]i agree that updating a dictionary is non-commutative. but does that mean it can't use |= ?? must | be used only in commutative cases?

It's not consistent. You have an operator working one way in one case, another way in another case. And I'm sure it's happening elsewhere in Python, but I think that sort of thing should be limited. I don't think having the syntactic sugar is a sufficiently compelling reason to break that consistency.

so you consider the commutative aspect to be part of the definition of consistency, e.g. even though the types can result in different actions (arithmetic addition in one case but not the other) that is unimportant for "consistency", but the commutativity is important.

I don't think commutivity is part of consistency, I think this working the same is consistency. And, yes, that is the definition of consistency: things remaining the same. Different types resulting in different actions is inconsistency. I have already admitted it exists, I just don't see the need to introduce more of it for syntactic sugar we don't really need.

(Nov-21-2018, 09:01 PM)Gribouillis Wrote: [ -> ]I've found (or my search engine found) a nice discussion about this topic.

interesting reading. the first corner case example seems wrong. why should t[0] += [1] result in a setitem applied to t? there is actually an assignment ambiguity (because immutables are allowed to reference mutables). if the expected end result is that the tuple continues to reference the same list, then no attempt should be made to change the tuple. the real issue is the tradition in programming languages where thing[index] can represent the value from within some object or modify the object. which is t[0] really supposed to do? setitem(t, 0, getitem(t, 0).__iadd__([1])) is doing both changes. how would this have been resolved had an immutable object not been allowed to reference a mutable object? at least we would not have to deal with issues like hash(((((([0],),),),),)) in such a case.