Pre-PEP: Dictionary accumulator methods

[Michele Simionato]

Raymond Hettinger:
> Any takers for tally()?

Dunno, to me "tally" reads "counts the numbers of votes for a candidate
in an election".

> 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.

I agree with Paul Rubin's argument on that issue, let's use increment()
and do not
worry about negative increments.

> > 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?

Well, I have used setdefault *very few times* in years of heavy Python
usage.
His disappearence would not bother me that much. Grepping my source
code I find that practically
my main use case for setdefault is in a memoize recipe where the result
of a function call
is stored in a dictionary (if not already there) and returned. Then I
have a second case
with a list as second argument.

> > 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.

Honestly, I don't care about the performance arguments. However I care
a lot about
about readability and clarity. setdefault is terrible in this respect,
since most
of the time it does *not* set a default, it just get a value. So I am
always confused
and I have to read at the documentation to remind to myself what it is
doing. The
only right name would be "get_and_possibly_set" but it is a bit long to
type.

> 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.

Well, I never figured out that the intent of setdefault was to build up
a list ;)

Anyway, if I think at how many times I have used setdefault in my code
(practically
twice) and how much time I have spent trying to decipher it (any time I
reread the
code using it) I think I would have better served by NOT having the
setdefault
method available ;)

About appendlist(): still it seems a bit special purpose to me. I mean,
dictionaries
already have lots of methods and I would think twice before adding new
ones; expecially
methods that may turn out not that useful in the long range, or easily
replaceble by
user code.


                             Michele Simionato