[Python-3000] Python-3000 Digest, Vol 2, Issue 151
Greg Wilson
gvwilson at cs.utoronto.ca
Wed Apr 26 14:40:11 CEST 2006
> From: Talin <talin at acm.org>
> In my experience dict literals are far more useful than set literals. In fact, I
> don't think I've ever made a set literal.
I think this is because:
a) sets are new to Python --- habit and examples both encourage us to use
lists, even when the collections in question aren't intrinsically
ordered; and
b) the current notation is unpleasant --- I appreciate Raymond et al's
dislike of egregious punctuation (it's why we all abandoned Perl,
right?), but {1, 2, 3} *is* a lot cleaner than set([1, 2, 3]).
I think the second half of (a) is important: we all use lists (or tuples)
to hold unordered collections because that's what we're used to, and
because until recently, that's all we had. In contrast, flip through a
copy of Aho, Hopcroft, and Ullman (if you're old enough to have it on your
shelf ;-). I didn't see any examples of maps (dicts) outside the sections
that are devoted to their design and implementation, but dozens of
algorithms use sets. I think that the smaller we make the gap between
what people write when they aren't constrained by implementation, and what
they write when implementing, the better off we'll all be.
> From: Aahz <aahz at pythoncraft.com>
> My opinion: if we were designing Python from scratch right now, we might
> well consider having only set literals and not dict literals. However,
> I don't think we can have both set and dict literals, and I think that
> removing dict literals (or list literals) counts as gratuitous breakage.
I agree that we can't remove dict or list literals; I don't see why we
can't have both sets and dicts. I'll bet a bottle of Macallan that
newcomers will stumble over the set/dict distinction and notation less
often than they currently do over the list/tuple distinction --- given an
implementation, it's something we could actually measure by looking at
error rates on introductory programming exercises.
Thanks,
Greg
More information about the Python-3000
mailing list