[Python-Dev] Proposal: defaultdict (original) (raw)
Adam Olsen rhamph at gmail.com
Mon Feb 20 19:22:30 CET 2006
- Previous message: [Python-Dev] Proposal: defaultdict
- Next message: [Python-Dev] Proposal: defaultdict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Proposal: defaultdict
- Next message: [Python-Dev] Proposal: defaultdict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]