a dictionary from a list

[George Sakkis]

"Steven D'Aprano" wrote:

> On Sat, 25 Jun 2005 06:44:22 -0700, George Sakkis wrote:
>
> > "Roy Smith" <roy at panix.com> wrote:
> >
> >> I just re-read the documentation on the dict() constructor.  Why does it
> >> support keyword arguments?
> >>
> >>    dict(foo="bar", baz="blah") ==> {"foo":"bar", "baz"="blah"}
> >>
> >> This smacks of creeping featurism.  Is this actually useful in real code?
> >> It took me several readings of the doc to understand what this was doing.
> >> Essentially, it's Perl's bareword syntax, and once I realized that, I
> >> simultaneously understood what was happening and was revolted that Python
> >> seems to have picked up one of Perl's most bizarre and confusing features.
> >
> > The worst thing about this form of the dict constructor it's not the
> > syntax; I think this becomes obvious after you've seen it once. More
> > annoying is that it "wastes" keyword arguments that could otherwise be
> > used to determine the characteristics of the dict. Perhaps the most
> > common desired feature is setting a default value for the dict, that
> > would allow for instance:
> >
> > wordCount = dict(default=0)
> > wordPos = dict(default=[])
> > for pos,word in enumerate(text):
> >     wordCount[word] += 1
> >     wordPos[word].append(pos)
> >
> > Other candidate optional arguments would allow type checking (e.g.
> > dict(keys=int, values=list)) or performance fine-tuning (e.g.
> > dict(minsize = 10, maxsize = 10000, average = 200)). I hope the
> > decision for this form of the constructor is reconsidered for python
> > 3K.
>
> Since Python dicts don't have default values, or type-checking, or
> user-editable performance fine-tuning, or for that matter any optional
> arguments, it is hardly possible to "waste" keyword arguments for a
> function that doesn't need any keyword arguments.
>
> What you actually mean to say is that the use of keyword arguments as
> "bareword" syntax for initialising dicts conflicts with the use of keyword
> arguments for non-existent, hypothetical and/or user-defined classes.
>
> That's okay. I'm perfectly comfortable with the fact that the syntax for
> initialising a dict conflicts with the syntax for initialising a list, a
> Decimal, a MutableString, and a ConfigParser object.
>
> So why should I be distressed that it conflicts with the syntax for
> initialising MyDictWithDefaultValue objects?

Because this specific use case at least is/was considered useful enough
to start off a thread that invited over a hundred posts on a pre-PEP
suggesting two new accumulator methods (http://tinyurl.com/aqpk3).
Default-valued dicts make the two proposed methods redundant and are a
more elegant solution to the dictionary based accumulation problem. So
yes, one can write MyDictWithDefaultValue (and I'm sure many have), but
the keyword-arg dict constructor prevents python from including it in
the future without breaking backwards compatibility.
 
George