dict.setdefault() (Patch#101102) (was: Re: [Python-Dev] Re: A small proposed change to dictionaries' "get" method...)

[Tim Peters]

[Skip Montanaro, on .getorset]
> Shouldn't that be getorsetandget?  After all, it doesn't just set
> or get it gets, but if it's undefined, it sets, then gets.

It's mnemonic enough for me.  You can take comfort in that Guido seems to
like "default" better, and is merely incensed by arguments about names
<wink>.

> I know I'll be shouted down, but I still vote against a method that both
> sets and gets dict values.  I don't think the abbreviation in the
> source is worth the obfuscation of the code.

So this is at least your second vote, while I haven't voted at all?  I
protest.

+1 from me.  I'd use it a lot.  Yes, I'm one of those who probably has more
dicts mapping to lists than to strings, and

    if dict.has_key(thing):
        dict[thing].append(newvalue)
    else:
        dict[thing] = [newvalue]

litters my code -- talk about obfuscated!  Of course I know shorter ways to
spell that, but I find them even more obscure than the above.  Easing a
common operation is valuable, firmly in the tradition of the list.extend(),
list.pop(), dict.get(), 3-arg getattr() and no-arg "raise" extensions.  The
*semantics* are clear and non-controversial and frequently desired, they're
simply clumsy to spell now.

The usual ploy in cases like this is to add the new gimmick and call it
"experimental".  Phooey.  Add it or don't.

for-that-matter-i'm-a-fan-of-"from-m-import-x-as-y"-too-ly y'rs  - tim