From: Raymond Hettinger
[Bob Ippolito]
d.setdefault(k, factory=list).append(v) ?
That is somewhat nice and backwards compatible too.
-1 How is it more expressive than d.setdefault(k, []).append(v)? As far as I can see, it's longer and contains an extra obscure(ish) term (factory). And I agree with the other posters that other defaults are often useful, and further complicating the dictionary interface isn't particularly helpful. If conciseness is important, def addlist(d, k, v): d.setdefault(k, []).append(v) Paul.
On Tue, 2004-01-20 at 09:41, Moore, Paul wrote:
From: Raymond Hettinger
[Bob Ippolito]
d.setdefault(k, factory=list).append(v) ?
That is somewhat nice and backwards compatible too.
-1
How is it more expressive than d.setdefault(k, []).append(v)? As far as I can see, it's longer and contains an extra obscure(ish) term (factory).
One benefit is that it doesn't create an unnecessary empty list when the key is already in the dictionary.
And I agree with the other posters that other defaults are often useful, and further complicating the dictionary interface isn't particularly helpful.
If conciseness is important,
def addlist(d, k, v): d.setdefault(k, []).append(v)
Nonetheless, I agree that the dict API is already quite large and the benefit of this new/changed method is very small. Jeremy
On Tue, Jan 20, 2004 at 09:46:02AM -0500, Jeremy Hylton wrote:
On Tue, 2004-01-20 at 09:41, Moore, Paul wrote:
From: Raymond Hettinger
[Bob Ippolito]
d.setdefault(k, factory=list).append(v) ?
That is somewhat nice and backwards compatible too.
-1
How is it more expressive than d.setdefault(k, []).append(v)? As far as I can see, it's longer and contains an extra obscure(ish) term (factory).
One benefit is that it doesn't create an unnecessary empty list when the key is already in the dictionary.
This sounds like a benefit if it is faster to not create the empty list? Naive preliminary testing does not indicate that it is, I imagine due to the keyword argument overhead. My test functions: def foo(x, y=None, z=None): pass def f1(): for x in xrange(10000000): foo(10, []) def f2(): for x in xrange(10000000): foo(10, z=list) 7.8 and 8.8 seconds to execute, respectively. Since f1 and f2 aren't C functions, maybe it's not an accurate prediction of how setdefault would behave... but it does seem that object creation overhead is pretty minimal. For other cases, where the overhead is much greater, it might be a different story. My own code shows no examples of that though (actually I seem to only use setdefault with 2 defaults, None and []). Jp
Regarding d.setdefault(k, factory=list).append(v): Moore, Paul writes:
How is it more expressive than d.setdefault(k, []).append(v)? As far as I can see, it's longer and contains an extra obscure(ish) term (factory).
The advantage I see is that it delays creation of the object being used as the default value; no list is created unless needed, whereas the setdefault() invocation shown always creates a new list, even if it's going to be thrown away. In many situations, if you're really using a list, this doesn't matter, but in other cases, especially if you're using a more complex object (or one with a more expensive constructor), using the factory makes a lot of sense. The idea that "factory" is an obscure term for Python programmers is scary.
And I agree with the other posters that other defaults are often useful, and further complicating the dictionary interface isn't particularly helpful.
The basic setdefault() certainly remains useful on its own; I don't think anyone suggested otherwise. My objection is the complication of the dictionary interface; it has a lot of methods now, and avoiding new names with highly specialized meanings is good. -1 for addlist(k, v) -0 for setdefault(k, factory=...)
If conciseness is important,
def addlist(d, k, v): d.setdefault(k, []).append(v)
Yep. Or whatever variation makes sense in context. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
"Fred L. Drake, Jr." <fdrake@acm.org> writes:
The idea that "factory" is an obscure term for Python programmers is scary.
As a concept, it's possibly not obscure (although I'm introducing Python to colleagues at work, who are used to VB and SQL, and for whom "object" is a fairly novel term!) But it took me a while to figure out how it related to what's going on here. I got it, and it's now obvious, but that initial "huh?" feeling is probably worth watching out for :-) Paul. -- This signature intentionally left blank
Paul Moore writes:
As a concept, it's possibly not obscure (although I'm introducing Python to colleagues at work, who are used to VB and SQL, and for whom "object" is a fairly novel term!)
Interesting, and a good point. I guess it's not familiar to all programmers, especially where the idiom isn't common. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
participants (5)
-
Fred L. Drake, Jr. -
Jeremy Hylton -
Jp Calderone -
Moore, Paul -
Paul Moore