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 -- http://mail.python.org/mailman/listinfo/python-list