On 2/20/06, Aahz <aahz at pythoncraft.com> 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? > 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? -- Adam Olsen, aka Rhamphoryncus
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4