dict literals vs dict(**kwds)

[George Sakkis]

Bruno Desthuilliers wrote:

> George Sakkis a écrit :
> > The thing is there are four (at least?) ways to get a dict instance:
> >
> > In [1]: d1={'name':'mike', 'age':23}
> >
> > In [2]: d2=dict(d1)
> >
> > In [3]: d3=dict(**d1)
> >
> > In [4]: d4=dict(d1.items())
> >
> > In [5]: d1==d2==d3==d4
> > Out[5]: True
> >
> > Talk about "there should be one and preferably one obvious way to do
> > it".
> >
>
> This actually makes 2 (two) ways of creating a dict:
> - the default call to type (ie : dict(...)
> - the syntactic sugar dict-litteral syntax.
>
> The fact that dict() takes either a sequence of pairs and/or keyword
> args (yes, you can use both at once) doesn't make for 2 distinct ways.
> And the second syntax (litteral) is nothing else than syntaxic sugar -
> read : a special case. So if we are to get rid of one or the other, it's
> the dict-litteral syntax that should go away.
>
> >
> >>>Perhaps it's something that should be reconsidered for Py3K
> >>
> >>Hopefully not. The fact that you fail to understand why a given feature
> >>exists and how it can be useful is not a reason to ask for arbitrary
> >>restrictions on the language.
> >
> >
> > Perhaps you fail to understand that the given feature is
> > 1) redundant (see above).
>
> see above for an answer on this. FWIW, there are a *lot* of other
> syntactic-sugar redundancy in Python. Most of which you're probably not
> even aware of.

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.

> > 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. Plus, adding new functionality
by subclassing often leads to combinatorial explosion (think of "class
OrderedDefaultPrettifiedDict(defaultdict, odict, prettydict)").

George