Pre-PEP: Dictionary accumulator methods
michele.simionato at gmail.com
Sat Mar 19 08:55:17 CET 2005
> 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()
> its "keywords" argument spelled-out). The only other issue I see with
> is that historically incrementing is more associated with +=1 than
> Also, there are reasonable use cases for a negative n and it would be
> 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
> > that often).
> I'm curious. When you do use setdefault, what is the typical second
Well, I have used setdefault *very few times* in years of heavy Python
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
> default value are not at all related. Do you prefer having the
> 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
> dot) method lookup and call for append or extend? When you first saw
> explained, was it immediately obvious or did it taking more learning
> other dictionary methods? To me, it is the least explainable
> Even when given a good definition of setdefault(), it is not
> that it is meant to be futher combined with append() or some such.
> code to newbies or non-pythonistas, do they find the meaning of the
> idiom self-evident? That last question is not compelling, but it
> with other Python code which tends to be grokkable by non-pythonistas
> > 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
> Eventhough a set operation only occurs conditionally, the get always
> The proposed name doesn't make it clear that the method alway returns
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,
of the time it does *not* set a default, it just get a value. So I am
and I have to read at the documentation to remind to myself what it is
only right name would be "get_and_possibly_set" but it is a bit long to
> Even if a wording is found that better describes the both the get and
> operation, it is still a distractor from the intent of the combined
> the intent of building up a list. That is an intrinsic wording
> 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
> 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
twice) and how much time I have spent trying to decipher it (any time I
code using it) I think I would have better served by NOT having the
method available ;)
About appendlist(): still it seems a bit special purpose to me. I mean,
already have lots of methods and I would think twice before adding new
methods that may turn out not that useful in the long range, or easily
More information about the Python-list