On 2/20/06, Jim Jewett <jimjjewett at gmail.com> wrote: > Adam Olsen asked: > > ... d.getorset(key, func) would work in your use cases? > > It is an improvement over setdefault, because it doesn't > always evaluate the expensive func. (But why should every > call have to pass in the function, when it is a property of > the dictionary?) Because usually it's a property of how you use it, not a property of the dictionary. The dictionary is just a generic storage mechanism. > [snip] > In other words, the program would work correctly if I passed > in a normal but huge dictionary; I want to avoid that for reasons > of efficiency. This isn't the only use for a mapping, but it is > the only one I've seen where KeyError is "expected" by the > program's normal flow. Looking at your explanation, I agree, getorset is useless for that use case. However, I'm beginning to think we shouldn't be comparing them. defaultdict is a powerful but heavyweight option, intended for complicated behavior. getorset and setdefault are intended to be very lightweight, even lighter than the "try/except KeyError" and "if key not in X: X[key] = default" memes we have right now. getorset's factory function is only appropriate for preexisting functions, not user defined ones. Essentially, I believe getorset should be discussed on its own merits, independent of the addition of a defaultdict class. Perhaps discussion of it (and the deprecation of setdefault) should wait until after defaultdict has been completed? -- 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