Pre-PEP: Dictionary accumulator methods

[Raymond Hettinger]

[Michele Simionato]
> +1 for inc instead of count.

Any takers for tally()?

We should avoid abbreviations like inc() or incr() that different people tend to
abbreviate differently (for example, that is why the new partial() function has
its "keywords" argument spelled-out). The only other issue I see with that name
is that historically incrementing is more associated with +=1 than with +=n.
Also, there are reasonable use cases for a negative n and it would be misleading
to call it incrementing when decrementing is what is intended.

The issue with add() is that other types with that method use it for a radically
different purpose.  For example, aSet.add(n) is not at all similar in function
to the proposed aDict.tally(n) or whatever it ends up being called.  Of course,
count() is also problematic because the meaning doesn't parallel that for
list.count().



> appendlist seems a bit too specific (I do not use dictionaries of lists
> that often).

I'm curious.  When you do use setdefault, what is the typical second argument?
In all the code I've encountered, nine times out of ten it is [].  In the rare
case of {}, the resulting statement is a mess because both the subkey and value
need to be applied -- a pure python equivalent is much clearer.  That leaves two
other mutable containers, set() and collections.deque() neither of which I've
ever seen used with setdefault().

IOW, I believe that, in practice, setdefault() is all about dictionaries of
lists.  If so, I'm recommending a method that gets straight to the point with no
fuss, no waste, and no obfuscation.

In order to have some unused and unneeded versatility with respect to the
default object, I'm asserting that we've been burdened with an awkward, slow
idiom that is unnecesarily hard to learn and explain.



> The problem with setdefault is the name, not the functionality.

Are you happy with the readability of the argument order?  To me, the key and
default value are not at all related.  Do you prefer having the default value
pre-instantiated on every call when the effort is likely to be wasted?  Do you
like the current design of returning an object and then making a further (second
dot) method lookup and call for append or extend?  When you first saw setdefault
explained, was it immediately obvious or did it taking more learning effort than
other dictionary methods?  To me, it is the least explainable dictionary method.
Even when given a good definition of setdefault(), it is not immediately obvious
that it is meant to be futher combined with append() or some such.  When showing
code to newbies or non-pythonistas, do they find the meaning of the current
idiom self-evident?  That last question is not compelling, but it does contrast
with other Python code which tends to be grokkable by non-pythonistas and
clients.



> get_or_set would be a better name: we could use it as an alias for
> setdefault and then remove setdefault in Python 3000.

While get_or_set would be a bit of an improvement, it is still obtuse.
Eventhough a set operation only occurs conditionally, the get always occurs.
The proposed name doesn't make it clear that the method alway returns an object.

Even if a wording is found that better describes the both the get and set
operation, it is still a distractor from the intent of the combined statement,
the intent of building up a list.  That is an intrinsic wording limitation that
cannot be solved by a better name for setdefault.  If any change is made at all,
we ought to go the distance and provide a better designed tool rather than just
a name change.



> Just my 2 Eurocents,

I raise you by a ruble and a pound ;-)


Raymond Hettinger