[Python-Dev] re: sets
Wed, 24 Jan 2001 09:10:41 -0500
1. I did a poll overnight by email of 22 friends and colleagues,
none of whom are regular Python users (yet). My question was,
"Would you expect the interface of a set class to be like
the interface of a vector or list, or like the interface
of a map or hash?"
15 people have replied; all 15 have said, "map or hash".
Several respondents are Perl hackers, so I'm sure the answer
is influenced by previous exposure to the set-as-valueless-hash
idiom. Still, I think 15-0 is a pretty convincing score...
Four, unprompted, said that they thought the STL's hierarchy of
containers was as good as it gets, and that other languages
should mirror it. (One of those added that this makes teaching
much simpler --- students can transfer instincts from one language
2. Is there enough interest in sets for a BOF at IPC9? Please
reply to me point-to-point if you're interested; I'll summarize
and post the result. I volunteer to bring the donuts...
> > Ka-Ping Yee:
> > The only change that needs to be made to support sets of immutable
> > elements is to provide "in" on dictionaries. The rest is then all
> > quite natural:
> > dict[key] = 1
> > if key in dict: ...
> > for key in dict: ...
> > various:
> > [but what about 'value in dict' or '(key, value) in dict'?]
> Fredrik Lundh:
> let's just say that "in" is the same thing as "has_key",
> and be done with it.
> Guido van Rossum:
> You know, I've long resisted this, but I agree now -- this is the
> right thing.
Woo hoo! Now, on a related note, what is the status of the 'indices()'
proposal, as in:
for i in indices(someList):
for i in range(len(someList)):
Would 'indices(dict)' be the same as 'dict.keys()', to allow
uniform iteration? Or would it be more economical to introduce
a 'keys()' method on lists and tuples, so that:
for i in collection.keys():
would work on dicts, lists, and tuples? I know that 'keys()'
is the wrong name for lists and tuples, but dicts are already
using it, and it's completely unambiguous...