a clean way to define dictionary

[Alexander Schmolck]

Michael Chermside <mcherm at mcherm.com> writes:

> Alexander Schmolck writes:
> > Maybe I'm a bit blinkered, but right now I can't see how
> > 
> >     dict(foo=1, bar='sean')
> > 
> > is so much better/more convinient than
> > 
> >     {'foo':1, bar:'sean'}
> 
> I think you've answered your own question. If you know that a particular
> dict is going to have simple string keys, then it's kind of a pain to
> remember to type the quotes around the keys. As evidence, I point to your
> own post, which should have been:
>       {'foo':1, 'bar':'sean'}

I can't remember having problems with this in practice (when I'm using a
syntax highlighting editor).

> Now, I'm not fully convinced that the new syntax useful enough to be
> worth having multiple ways to do it (one of which breaks as soon as
> you have a non-identifier key), but in the situation where it works,
> it's clearly (a little bit) more convenient.

I'm not saying it isn't (marginally) more convinient for a (common) special
case, but the bit you snipped asked whether it's worth the disadvantages.
Worse than a new, redundant, way to do things IMHO is that it also precludes
specifying options for dict instance creation (it's not that one couldn't come
up with some candidates) in the future and even makes subclasses of dict like
DefaultDicts that need such constructor options needlessly constructor
incompatible. I have yet to see a vaguely convincing example where the new
additional syntax conveys a non-marginal advantage and even if it did, why not
make it a classmethod or let the user write the necessary one-liner himself?
So why make python more perlish, for little apparent gain?

'as