[issue10533] defaultdict constructor with a concrete value

Alex added the comment: I agree with Łukasz, it's more clutter than is worth for what amounts to: fallbackdict = lambda c, **kwargs: defaultdict(lambda c, **kwargs) I will note, however, that almost all my use cases are with factories, primarily list set or int, and it was only this week that

[issue10533] defaultdict constructor with a concrete value

Steve Holden added the comment: On 11/25/2010 1:44 PM, Łukasz Langa wrote: > To sum up: if you don't find the idea of adding `fallbackdict' > (possibly with an different *short* name) worth it, then I'm +1 on > correcting the docs in terms of __missing__ and leaving the > implementation as is.

[issue10533] defaultdict constructor with a concrete value

Łukasz Langa added the comment: A couple of points: 1. Eric's proposal is what I had in mind with the `fallbackdict' idea. 2. I'm also reluctant to add more variants to the standard library. Then again if it contained a `fallbackdict' I wouldn't probably ever use `defaultdict' again. How ofte

[issue10533] defaultdict constructor with a concrete value

Raymond Hettinger added the comment: > It would be very handy to allow for concrete values as well. Do you have use cases for a concrete integer value that isn't zero? Since we can currently use defaultdict(int) or defaultdict(tuple), is the purpose just to create a more direct spelling of th

[issue10533] defaultdict constructor with a concrete value

Changes by Raymond Hettinger : -- assignee: lukasz.langa -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list m

[issue10533] defaultdict constructor with a concrete value

Éric Araujo added the comment: Like three-liners? whatsnew/2.5 gives us this one: class zerodict(dict): def __missing__(self, key): return 0 I don’t think it’s too painful to have to use defaultdict with a lambda. We can’t use a keyword argument and I’m -0.5 on changing behavior

[issue10533] defaultdict constructor with a concrete value

Steve Holden added the comment: On 11/25/2010 11:48 AM, Eric Smith wrote: > > Eric Smith added the comment: > > How about: > > from collections import defaultdict > > class defaultdict_value(defaultdict): > def __init__(self, value): > defaultdict.__init__(self, lambda : value)

[issue10533] defaultdict constructor with a concrete value

Eric Smith added the comment: How about: from collections import defaultdict class defaultdict_value(defaultdict): def __init__(self, value): defaultdict.__init__(self, lambda : value) x = defaultdict_value(3) print(x[1]) -- ___ Python

[issue10533] defaultdict constructor with a concrete value

Łukasz Langa added the comment: Both arguments are true and definitive. Last possibility would be to introduce a factory function for defaultdicts that would only accept concrete values: from collections import fallbackdict Then this factory could produce defaultdict instances like this:

[issue10533] defaultdict constructor with a concrete value

Eric Smith added the comment: -1 from me. You can't use keywords, and if you make the value callable at a later date then suddenly you'll change the behavior of seemingly unrelated code. Is a lambda so bad? -- nosy: +eric.smith ___ Python tracker

[issue10533] defaultdict constructor with a concrete value

Michael Foord added the comment: I would love this functionality (I almost always initialise defaultdict with a lambda that just returns a concrete value). Unfortunately it seems like adding a keyword argument isn't possible because defaultdict takes arbitrary keyword args (and populates the

[issue10533] defaultdict constructor with a concrete value

New submission from Łukasz Langa : Currently the constructor in defaultdict only accepts factories. It would be very handy to allow for concrete values as well. It's implementable either by checking if the argument is callable or by a new keyword argument. -- assignee: lukasz.langa com