[Python-Dev] re: Using lists as sets (original) (raw)

gvwilson@nevex.com gvwilson@nevex.com
Mon, 20 Mar 2000 09:52:12 -0500 (EST)

[After discussion with Ping, and weekend thought]

I would like to vote against using lists as sets:

  1. It blurs Python's categorization of containers. The rest of the world thinks of sets as unordered, associative, and binary-valued (a term I just made up to mean "containing 0 or 1 instance of X"). Lists, on the other hand, are ordered, positionally-indexed, and multi-valued. While a list is always a legal queue or stack (although lists permit state transitions that are illegal for queues or stacks), most lists are not legal sets.

  2. Python has, in dictionaries, a much more logical starting point for sets. A set is exactly a dictionary whose keys matter, and whose values don't. Adding operations to dictionaries to insert keys, etc., without having to supply a value, naively appears no harder than adding operations to lists, and would probably be much easier to explain when teaching a class.

  3. (Long-term speculation) Even if P3K isn't written in C++, many modules for it will be. It would therefore seem sensible to design P3K in a C++-friendly way --- in particular, to align Python's container
    hierarchy with that used in the Standard Template Library. Using lists as a basis for sets would give Python a very different container type hierarchy than the STL, which could make it difficult for automatic tools like SWIG to map STL-based things to Python and vice versa. Using dictionaries as a basis for sets would seem to be less problematic. (Note that if Wadler et al's Generic Java proposal becomes part of that language, an STL clone will almost certainly become part of that language, and require JPython interfacing.)

On a semi-related note, can someone explain why programs are not allowed to iterate directly through the elements of a dictionary:

for (key, value) in dict: ...body...

Thanks,

Greg

  "No XML entities were harmed in the production of this message."