On 7/9/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > Phillip, I support any initiative to keep .setdefault() or similar > functionality. When this thread came up before, I wasn't against > defaultdict, I just didn't think it covered enough of the use cases > of .setdefault() to warrant its removal. You describe some > additional use cases. > > However, .setdefault() is a horrible name because it's not clear from > the name that a 'get' operation also happens.
We had a long name discussion when it was introduced. Perhaps we can go back to the list suggested then and see if a better alternative was overlooked? > It occurs to me that I haven't reached my stupid idea quota for the > day, so here goes. What if we ditched .setdefault() as a name and > gave .get() an optional argument to also set the key's value when > it's missing. > [...] > def get(self, key, default=None, set_missing=False): > missing = object() > value = super(dict2, self).get(key, missing) > if value is not missing: > return value > if set_missing: > self[key] = default > return default > > This more or less conveys that both a get and a set operation is > happening. It also doesn't violate the rule against letting an > argument change the return type of a function. Maybe it will make > this useful functionality more palatable. But it does violate the rule that if you have a boolean flag to indicate a "variant" of an API and in practice you'll always be passing a constant for that flag, you're better off defining two methods with different names. Although if the return type isn't different, the semantics are certainly *very* different here. So I'm strongly against this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
