dict literals vs dict(**kwds)

[Bruno Desthuilliers]

George Sakkis a écrit :
> Bruno Desthuilliers wrote:
> 
> 
>>George Sakkis a écrit :
>>
>>>The thing is there are four (at least?) ways to get a dict instance:
>>>
(snip)

>>This actually makes 2 (two) ways of creating a dict:
>>- the default call to type (ie : dict(...)
>>- the syntactic sugar dict-litteral syntax.
>>
(snip)
> 
> Even without the syntactic-sugar form, I fail to see why you seem to
> think that dict(items), dict(otherdict) and dict(**kwds) are all one
> thing.

Of course it's all one thing: a call to a callable that happens to be a 
factory for dict instances.

> 
>>>2) restricting in a more serious sense: the future addition of optional
>>>keyword arguments that affect the dict's behaviour.
>>
>>This has already been discussed, and IIRC no-one managed to make a
>>*serious* point about it. The actual signature of dict() is perfectly
>>sensible for 99% of uses case, and I *never* had a need for "keyword
>>arguments that affect the dict's behaviour" in 6+ years of Python
>>programming.
>>
>>If you want another behaviour, feel free to subclass dict or implement
>>your own dict-like - FWIW, that's what I do when the need arises.
> 
> 
> Me too, but I'd gladly toss them if one day dicts were extended to
> accept, say a default value or ordering. 

Ordering ? What "ordering" ?

Anyway, there's no need to change the actual constructor for this - just 
adding a factory would be enough:

d = dict.with_default(default)

But I'm actually -1 on this. I don't like the idea of a dict with 
default values for non existing keys.

> Plus, adding new functionality
> by subclassing often leads to combinatorial explosion

Yes - and this is usually solved with either decorators (the design 
pattern - not our beloved @decorators) and/or strategy.

Also, this is more of a statically-typed langages problem. With dynamic 
typing, inheritance is only about implementation. Please re-read what I 
said : "to subclass dict or implement your own dict-like". There was a 
time when subclassing wasn't even an option.

> (think of "class
> OrderedDefaultPrettifiedDict(defaultdict, odict, prettydict)").

I don't know what is supposed to be a "prettydict". But even if your 
monster class is dict-like, it's clearly not a dict no more.