a dictionary from a list

Steven D'Aprano steve at REMOVETHIScyber.com.au
Sat Jun 25 14:33:15 EDT 2005


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?

-- 
Steven.




More information about the Python-list mailing list