a clean way to define dictionary

[Michael Chermside]

Alexander Schmolck writes:
> 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?

Well, I snipped it because I didn't have anything to say on it. And that's
because I basically agree with you. I'd say I'm -0 on this, or perhaps
-0.4 to be more precise. I don't see that it's necessary, and it does
have some mild disadvantages. But I also think the disadvantages *are*
pretty mild, so I'm certainly not going to be the one to oppose it.

As Alex M. pointed out... once 2.3 goes out the door with this in it, 
the feature can never be removed. So if you *really* care about this, 
you should bring it up *NOW* on python-dev, providing cogent arguments
explaining why it's a bad idea. Me, I think it's not such a big deal.

-- Michael Chermside