[Python-ideas] Add dict.append and dict.extend

[Steven D'Aprano]

On Tue, Jun 05, 2018 at 09:44:59AM -0700, Chris Barker via Python-ideas wrote:

> I think your proposal got a bit confused by the choice of names, and that
> you were proposing two things, one of which I think already exists
> (setdefault).

Ben's very first paragraph in this thread says:

    I'd like to propose adding `append` and `extend` methods to
    dicts which behave like `__setitem__` and `update` respectively,
    except that they raise an exception (KeyError?) instead of 
    overwriting preexisting entries.


setdefault does not raise an exception. So while your enthusiasm does 
you credit (setdefault is an excellent little method that is not known 
anywhere near as well as it ought to be) I don't think it is the least 
bit relevant here.

Ben's proposal is for something like your exclusive_add below (although 
written in C so it would be atomic), and then given that, something 
like:

def exclusive_update(self, other):
    # simplified version
    for key in other:
        self.exclusive_add(key, other[key])

except that it isn't clear to me what should happen if a key matches:

1) should the update have an "all or nothing" guarantee?
   (either the entire update succeeds, or none of it)

2) if not, what happens on partial success? are the results
   dependent on the order of the attempted update?


> So, I _think_ what you are proposing is that there be a method something
> like:
> 
> def exclusive_add(self, key, value):
>     if key in self:
>         raise KeyError("the key: {} already exists in this
> dict".format(key))
>     self[key] = value
> 
> Which would make sense if  that is a common use case, and you make a pretty
> good case for that, with the analogy to UNIQUE in database tables.

I'm not sure that it is so common. I think I've wanted the opposite 
behaviour more often: aside from initialisation, only allow setting 
existing keys, and raise if the key doesn't exist.

Nor do I think the DB analogy is very convincing, since we have no 
transactions with ACID guarantees for dicts. Pretty much the only 
similarity between a dict and a DB is that they both map a key to a 
value.


> I will point out that  the DB case is quite different, because python dicts
> have a way to of spelling it that's really pretty straightforward,
> performant and robust.

I'm confused... first you say that Ben makes a good case for this 
functionality with the DB analogy, and then one sentence later, you say 
the DB case is very different. So not a good case? I don't understand.

And what is this way of spelling "it" (what is it?) that's 
straightforward and robust? You've completely lost me, sorry.


-- 
Steve