On Mon, Feb 20, 2006, Adam Olsen wrote: > On 2/20/06, Aahz <[EMAIL PROTECTED]> wrote: >> On Sun, Feb 19, 2006, Josiah Carlson wrote: >>> >>> I agree, there is nothing perfect. But at least in all of my use-cases, >>> and the majority of the ones I've seen 'in the wild', my previous post >>> provided an implementation that worked precisely like desired, and >>> precisely like a regular dictionary, except when accessing a >>> non-existant key via: value = dd[key] . __contains__, etc., all work >>> exactly like they do with a non-defaulting dictionary. Iteration via >>> popitem(), pop(key), items(), iteritems(), __iter__, etc., all work the >>> way you would expect them. >> >> This is the telling point, IMO. My company makes heavy use of a "default >> dict" (actually, it's a "default class" because using constants as the >> lookup keys is mostly what we do and the convenience of foo.bar is >> compelling over foo['bar']). Anyway, our semantics are as Josiah >> outlines, and I can't see much use case for the alternatives. > > Can you say, for the record (since nobody else seems to care), if > d.getorset(key, func) would work in your use cases?
Because I haven't been reading this thread all that closely, you'll have to remind me what this means. >> Those of you arguing something different: do you have a real use case >> (that you've implemented in real code)? > > (again, for the record) getorset provides the minimum needed > functionality in a clean and intuitive way. Why go for a complicated > solution when you simply don't need it? Ditto above. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com