On Thu, Feb 6, 2020 at 7:42 PM Musbur
Depends on what d is.
type({})
So the result is {(1, 2): None}, but the ambiguity comes from the definition of {}, not from my proposal.
Actually, what Serhiy hinted at was a consequence (and, I would say, a rather weird corner case) of the current definition of |= as being "equivalent to update()". Since update() will accept a number of things, including an iterable of pairs, it's actually possible to use a set of two-element tuples as a representation of keys and values. It seems pretty unlikely that anyone would use a *set* for this (as opposed to, say, a list or generator), but it does mean that your proposal would conflict with that. Which in turn means you're actually asking for |= to special-case sets; not impossible, by any means, but it's a definite change and not simply a logical extension of current behaviour. I don't think supporting sets in |= is worth this confusion, especially since there's no easy way to override the choice of value. It'd be just as easy to do thing|=dict.fromkeys(s) and avoid the whole issue. However, IMO the &= operator would be better able to accept a set, and this is something that wouldn't conflict (and thus can be safely added later). ChrisA